Каков стандартный способ синхронизации ветвления с совместными проектами?

Question

Новичок с открытым исходным кодом здесь.

Я разветвил репозиторий TortoiseGit на GitLab, затем клонировал его на моем компьютере, отредактировал один файл и зафиксировал в ветке master.

Прошло несколько дней, и я хочу обновить свою локальную рабочую копию последними изменениями из апстрима, прежде чем отправлять на мой удаленный форк и открывать запрос на слияние (и, конечно, делать больше разработки / тестирования и т. Д.).) .

Я добавил пульт дистанционного управления с именем upstream в свой репозиторий, и теперь я не уверен, что будет рекомендуемым действием:

1. git pull с upstream/master в мою проверенную ветку master
2. git pull --rebase //
3. git fetch, за которыми следует git rebase.

Это подходыЯ нашел во время моего исследования.К сожалению, я не смог найти исчерпывающий обзор каждого из них, ни рекомендации относительно того, какой из них является типичной практикой при работе с проектами из GitHub, GitLab или даже с такими, как ядро ​​Linux.

Я пробовал методы 1 и 3.Метод 1 (pull) генерирует коммит слияния (--ff-only невозможен), и моя история, в некотором смысле, загрязнена.Это также создает конфликты.Метод 3 (rebase) не делает ни того, ни другого, но я не уверен, как ведет себя rebase после передачи коммитов на удаленный компьютер, и поэтому я боюсь, что это может вызвать проблемы в будущем.

Так что мой вопрос.
Спасибо.

Answer 1

Член команды TortoiseGit здесь.

Я добавил пульт дистанционного управления, называемый upstream, в свое хранилище, и теперь я не уверен, что будет рекомендуемым действием:
1. git pull from upstream /master к моей проверенной ветке master
2. git pull --rebase //
3. git fetch с последующим git rebase.

Различное использование командыдругой рабочий процесс.
См. Pro Git (v2) - 5.1 Распределенный Git - Распределенные рабочие процессы

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

Итак, большую часть времени мы используем « git fetch, за которым следует git rebase », особенно при содействии.Затем, как вы сказали, создайте запрос pull / merge (используя git push) или обновите запрос pull / merge (используя git push с принудительной ) в GitHub / GitLab.

См. Как я могу внести свой вклад? и HowToContribute.txt для получения дополнительной подробной информации.

Answer 2

Я разветвил репозиторий TortoiseGit на GitLab, затем клонировал его на своем компьютере, отредактировал один файл и передал в мастер веток Несколько дней прошло, и я хочу обновить свою локальную рабочую копию последними изменениями из апстрима

Если вы ссылаетесь на основной репо в вышестоящем потоке, вы можете

1. git fetch origin
2. git rebase origin/master

при условии, что origin указывает на главный репо

Перебазировка повторяет коммиты вашей текущей ветви (вашей локальной master ветви) поверх ветви, которую вы перебираете origin/master в этом случае,которая является ссылкой на текущую ветку master origin.

Например:

master ветка перед вашей фиксацией:

• c
• b
• a

master ветвь после вашего коммита:

• xxx <- ваш коммит </li>
• c
• b
• a

Через несколько дней TortoiseGit git фиксирует origin/master, что теперь выглядит следующим образом.

• 3
• 2
• 1
• c
• b
• a

Вы синхронизируетеизменения путем выборки и перебазирования поверх origin/master.Ваша локальная ветка master теперь будет выглядеть следующим образом:

• xxx <- ваш коммит </li>
• 3
• 2
• 1
• c
• b
• a

Я добавил в репо пульт, называемый upstream, и теперь я не уверен, что будетрекомендуемое действие

, тогда вы можете просто git push upstream master обновить свой форк.