Обновление мастер-ветки: git pull VS git pull --rebase?
Задача — подтянуть последние изменения из origin-ветки и не «захламить» историю.
1) Традиционный вариант — (master) $ git pull origin master, однако он делает merge и оставляет «отметку» мержа.
2) Сделать (master) $ git pull --rebase origin master, что полностью заменяет содержимое репозитория на последнее актуальное (за исключеним локальных коммитов).
Правильно ли я понимаю оба варианта? Если да, то какой вариант «правильнее» решает поставленную задачу?
Вы неправильно поняли второй вариант git pull --rebase origin master,
он убирает ваши локальные коммиты, обновляет ветку (обычно это fast-forward), и потом после обновления снова применяет ваши коммиты.
А git fetch обновляет ваш origin репозиторий, но не применяет полученные изменения с вашими рабочими копиями
Спасибо. То есть, если в мастере нет моих коммитов (а вся разработка идет в некой фича-ветке), то pull --rebase просто все обновит?
Стоп, в аналогичной ситуации git pull сделал бы такой же fast-forward merge, так?
Получается, что в случае отсутствия коммитов как обновлять разницы нет.
Если у вас нет ваших локальных коммитов в обновляемой ветке, то разницы нет, он сделает FF. Как я заметил, разница в том что, если у вас есть измененные файлы (не закоммиченные, а просто измененные, например конфиг какой-то), то git не позволит вам сделать pull --rebase пока не откатите внесенные изменения, а pull позволит, но только если не приходят изменения в измененном вами файле.
И команда git pull, оно не обновляет полносьтю всё. Она забирает все новые изменения с удаленного репозитория, помещает их в ваш origin, но сливает новые изменения только для текущей или указанной локальной ветки. Т. е. git pull [--rebase] origin master заберет все изменения с удаленного origin, применит к вашему origin и сольет изменения в локальный master. При этом если пришли изменения в ветке live, то ваш локальный live и ваш origin/live будут отличаться пока вы не переключитесь на свой локальный live и не сделаете заново git pull или git merge origin/live. Иначе говоря git pull = git fetch + git merge
Немного не то, но спасибо: «With --no-commit perform the merge but pretend the merge failed and do not autocommit, to give the user a chance to inspect and further tweak the merge result before committing».