Это огромная работа, очень нужная.  Основной справочник по telegramm я постоянно с ним сверяюсь.

@kerby_fc здесь говорят про bash и как выяснилось не только. Этот чел веб-разраб, мой друг

Привет!

Получается после токго как я сделал fork - git clone - надо еще и git pull делать.   Там еще пара чатов в этот момент добавилась, или fork с git clone дали не последнюю версию?

Александр привет.

А еще лучше git pull --rebase

Что то вообще какая-то фантастика.  форкнул, отклонировал, добавил строчку,  а у меня родитель моего коммита от 27 ноября 2017 года.

Потому что git pull --rebase нужен

Буду знать.

протому что раньше я думал что получаю самый свежак.

Понял сразу на верх закидываем комиты.

Хотя не до кона понял, но хоть что-то прояснилось.

Допустим ты отклонировал три коммита с сервера origin в ветке master : originA-originB-originC, где originX - хэш коммита
После этого ты имеешь копию репозитория.
Есть также References -- именные указатели на коммиты. Их называют ветками в git. Например
originA - originB - originC <- master, origin/master, HEAD
Где origin/master -- reference или ветка, который тебе прилетел с сервера origin. master - твой локальный ref, который сразу после клонирования совпадает с origin/master. HEAD - автоматический ref на текущий коммит.

Внес изменения и сделал свой коммит yourD. В это время куча сусликов уже понаделали коммитов в удаленном origin. Получаем картину, например
У тебя локально: origA - origB - origC (origin/master) - yourD (master, HEAD). Т.к. ты стоял на ветке master, то этот ref сдвинулся и теперь кажет на твой новый коммит, HEAD как было сказано двигается всегда

На сервере origin после правок сусликов имеем
origA - origB - origC - origD - origE (origin/master)

Итак после коммита origC ваши истории с сервером расходятся , т.к. у последующих коммитов разные хэшт и их даже потенциально разное количество

И вот ты хочешь влить свои правки. Следим за руками

внимательно читаю.

git pull == git fetch && git merge -- затащить из сервера (по умолчанию origin) изменения, и создать мёрж-коммит, в котором будет слияние изменений (по умолчанию мёржим из дефолтнтного origin сервера ветку, с которой связана наша текущая ветка, в твоем случае мастер связан с origin/master)
Итак имеем у тебя
origA - origB - origC - дальше идет вилка
1. yourD
2. origD - origE (origin/master)
Дальше 1 и 2 сливаются в новом коммите
mergeYourAndOrigin (master, HEAD)

Если ты посмотришь на родительский коммит мёрд коммита, то увидишь, что у него два коммита родителя. Если бы ты просто сделал git fetch, то получил бы

origA - origB - origC - вилка
1. yourD (master, HEAD)
2. origD, origE (origin/master)

Если просто сделав fetch, ты сделаешь git push, то гит скажет: эй бро э, у тебя есть ветка master, которая связана с удаленной веткой origin/master, но ваши путм разъехались, иди нафиг

ясно.

Или вот второй способ вновь объединить СССР

git pull --rebase == git fetch origin && git rebase origin/master
Этим ты говоришь. Я хочу после стягивания изменений из origin, переставить свои изменения им в хвост и получить линейную цепочку

origA - origB - origC - origD - origE (origin/master) - yourD (master, HEAD)

И теперь, как и в случае с мёрж на выходе ты не имеешь вилки

делаешь git push и после этого получаешь

origA - origB - origC - origD - origE  - yourD (master, origin/master, HEAD)