Git - Merge vs Rebase для моего рабочего процесса

Question

Я читал о том, как работают операции git merge и git rebase , и я думаю, что у меня есть базовое понимание различий.Я видел диаграммы :-) Несмотря на это, мне все еще не ясно, что будет лучшим из двух, чтобы использовать для моего текущего рабочего процесса.

Моя работа использует perce в качестве системы SCM, но я использую git локально, чтобы отслеживать локальные изменения, выполнять рефакторинг и кучу другихклассные вещи, которые мерзавец может принести на стол.Я знаю, что уже существует инструмент, помогающий объекту работать с git и performance (например, p4-git), но я не обязательно хочу / нуждаюсь в таких накладных расходах, поэтому я стараюсь сделать вещи максимально простыми.Вот краткое описание моего текущего рабочего процесса для создания локальных веток git и последующей интеграции обратно в наш основной депозитарий:

1. У меня есть master git branch, которая выполняет ночную синхронизацию p4 с нашей кодовой базой.После выполнения синхронизации я фиксирую все изменения в основной ветке.По сути, моя ветка git master по сути представляет собой снимок последнего кода, внесенного в нашу основную линию Perforce.

2. Для локальных изменений, над которыми я работаю, я всегдасначала создайте ветку git и извлеките эту ветку во время работы над изменением.

3. Время от времени я хочу обновить свою ветку до последней версии от master .До сих пор я только что выполнил команду git merge master , и она работала нормально.

4. Когда я готов принять обязательство по фактическому депо перфектов, я объединяю свою ветку с моей веткой master , проверяя master и выдачу git merge BRANCH , а затем отправку с использованием обычных команд перформанса

Учитывая мой рабочий процесс, действительно ли я должен использовать мастер git rebase команда для шага № 3 вместо git merge master ?Исходя из моего понимания команды rebase , это было бы необходимо только в том случае, если, скажем, наша основная линия исполнения (удаленный склад) была разветвлена, и я хотел создать новый master основываясь на этой ветке (скажем, я называю это master-newbranch) и применил мои изменения к этой новой ветке.Мне нужно было бы перебазировать с этой ветки первым?

В общем, имеет ли смысл мой текущий рабочий процесс, или я уже приобрел некоторые вредные привычки?

Answer 1

У меня такой же рабочий процесс, и я предпочитаю использовать git rebase -i master. Это сохраняет все повторные синхронизации выполнения внизу списка изменений. Таким образом, кажется, я проверил последнюю версию и внес массу изменений. Кроме того, только изменения, относящиеся к ветви, отображаются после повторной синхронизации. Кажется более интуитивным, но это больше похоже на стиль, чем на корректность. ~ Бен

Answer 2

В этом случае вы не должны (обязательно) использовать rebase over merge. Помните, ребаз по существу переписывает вашу историю. Это полезно при очистке нескольких веток и предоставлении более линейной истории, но из вашего варианта использования вы ничего не получите, используя rebase. Поведение, которое вы описали, является нормальным рабочим процессом git, для которого было разработано слияние.

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

Answer 3

Rebase переписывает вашу историю. Так что действительно зависит от того, как вы хотите сохранить свою историю. Rebase делает историю более понятной в целом.

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

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