Ответ 1
Скажем, у вас есть эти репозитории Git:
- ваше личное репо, сидящее на вашем рабочем компьютере;
- ваше публичное репо,
you, где-то размещено; - основное репо,
origin, которое является основным деревом разработки.
Вы работаете над чем-то и совершили две коммиты A и B. Вы опубликовали их в своем публичном репо. В то же время origin имеет еще одну фиксацию Z.
/-A-B master, you/master
o-o-o
\-Z origin/master
Теперь позвольте сказать, что одному коллеге нужны ваши две фиксации, чтобы начать новую функцию. Он вытаскивает вашу ветку из вашего публичного репо и делает некоторые коммиты поверх этого.
/-C-D-E colleague/master
/-A-B master, you/master
o-o-o
\-Z origin/master
Теперь вы хотите добавить свои два, полностью протестированные, совершать над origin/master. Вы получаете из origin и делаете rebase (что эквивалентно git pull --rebase или git pull с опцией pull.rebase).
Это создает две новые коммиты. Вы нажимаете их на свое публичное репо и на origin. Чтобы усложнить ситуацию, скажем, после этого новый фиксатор F будет нажат на origin.
/-A-B-C-D-E colleague/master
o-o-o
\-Z-A'-B'-F master, you/master, origin/master
Теперь проблема заключается в том, что у вашего коллеги есть работа, основанная на двух "устаревших" фиксациях, и чтобы избежать дальнейших осложнений (конфликтов при слиянии, испортить историю), он должен переделать свою ветку поверх B "(скажем, он не делает не хочу F). Вам нужно рассказать ему об этом, иначе он, возможно, не заметит, что вы сделали.
/-C-D-E colleague/master
o-o-o-Z-A'-B'-F master, you/master, origin/master
Если вы не сказали ему, позже он объединит свою ветку в исходное положение, и история будет выглядеть так:
/-A-B-C-D-E
o-o-o \
\-Z-A'-B'-F-M colleague/master, origin/master
У вас в два раза больше A и B, но с разными именами. История становится сложнее читать, а вы будете сталкиваться с ужасными конфликтами слияния. И помните, этот пример довольно прост. Если в проекте работают десятки людей, и origin будет двигаться быстро, история скоро станет полным беспорядком.
Если это только один коллега, возможно, это хорошо. Но если вы не можете точно знать, кто вытащил вас, вы не можете знать, кого вы должны предупреждать. Это особенно актуально в разработке с открытым исходным кодом.
Основное правило: не перехватывать фиксации, которые вы уже опубликовали. Если A и B были только в вашем частном репо, перезагрузка в порядке и, вероятно, лучше всего, потому что это делает историю более простой и значимой. Расходящаяся история имеет смысл только тогда, когда ветвь имеет достаточные основания для существования (например, ветвь признака).