Синхронизация локальных веток репозитория git с изменениями из удаленного оригинала

Question

Я нашел много вопросов о синхронизации разветвленного репозитория git с исходным удаленным репозиторием, но ни одна из них не применима к моей конкретной проблеме.

Давайте предположим, что я разветвил проект с удаленным именем upstream , имя моего форка origin .У меня есть master и dev локально ветвь с этой дорожкой master и dev из origin .

Пока я не делаю никаких изменений в моем раздельном репо, я знаю, что могу синхронизировать свое разветвленное репо в origin с upstream / master на

git checkout master
git pull upstream master
git push origin master

Все идет нормально.Но теперь я работаю над своей локальной веткой dev и как только я закончу, я бы хотел объединить ее с моим локальным мастером.Но сначала я бы поставил в известность своего местного мастера с изменениями в upstream на

git checkout master
git pull upstream master
git push origin master

Первый вопрос (ы) : Это правильно?Но что тогда я буду делать с моей локальной веткой dev ?Перебазируйте его на моем обновленном master перед тем, как объединить его с моим локальным master или попробуйте объединить его без перебазирования?Или я должен пытаться постоянно синхронизировать мой локальный dev с upstream / master , периодически вводя upstream / master ?

Как только это будет выполнено, я

git push origin master

удаляю свою ветку dev локально и в origin .Но теперь мой master (локально и в origin ) отличается от upstream / master изменениями, сделанными моим локальным dev .

Второй вопрос : Как правильно теперь идти в ногу с синхронизацией с upstream / master ?Я все еще просто делаю

git checkout master
git pull upstream master
git push origin master

или что-то еще рекомендуется здесь (например, некоторая форма перебазировки)?Если бы я снова создал ветку dev , применил бы я ту же стратегию, которая применялась для первого вопроса снова, или применимо что-то еще?

Спасибо за вашу помощь!

Answer 1

Вопрос 1:

Я бы сказал, что в любом случае все в порядке. По моему опыту что-то вроде этого обычно работает довольно хорошо:

• Когда вы объединяетесь с upstream / master в local / master, имеет смысл перебазировать local / dev.
• Сбрасывая dev, когда вы получаете изменения в master, вы уменьшаете размер слияния / ребазирования, который вы имели бы, когда вы хотите объединить dev обратно в master.
• Это работает до тех пор, пока вы всегда перебазируете изменения с мастера на dev

После того, как вы сделали с dev, вы можете либо выполнить ребазинг еще раз, а затем объединить с мастером, либо просто слить непосредственно с мастером. Вы можете изменить сообщение в коммите слияния, чтобы указать, что было в вашем слиянии.

Вопрос 2:

При слиянии из апстрима, если у вас нет каких-либо различий в вашем регионе или происхождении, слияния будут происходить быстро. Это в основном означает, что git просто накладывает коммиты из апстрима поверх того, что у вас было, и не будет никакого слияния конфликтов или чего-либо еще.

Из-за этого вам не нужно перебазировать или что-то еще. Как упомянуто выше, если вы работаете над чем-то в dev, может быть хорошей идеей будет перебазировать dev в этот момент, чтобы у вас было больше обновлений.

В тот момент, когда у вас есть изменения, которые отличаются от вышестоящих, у вас будет реальное слияние и возможность сделать ребаз, если вы того пожелаете.

Перебазировать или объединить?

Это в основном зависит от вас и от того, как вам нравится работать, но если вы подумываете о перебазировании, помните, что это меняет историю.

Если кто-то еще использует origin / master или origin / dev, и вы перебазируете его, возможно, они столкнутся с некоторыми проблемами при попытке объединить свою работу. Поэтому, как правило, если ветвь используется более чем одним человеком, вы должны использовать слияния. Никогда не используйте rebase (или что-либо еще, что изменяет историю), если ветвь использует более одного человека.