Сведения о методах слияния в GitHub

Параметры слияния запросов на вытягивание можно настроить в экземпляр GitHub Enterprise Server в соответствии с потребностями рабочего процесса и предпочтениями для управления журналом Git. Дополнительные сведения см. в разделе Настройка слияния запросов на вытягивание. Вы можете применить один метод слияния, например фиксация со сжатием или перемещение изменений из одной ветви в другую, включив нужный метод для репозитория.

Если щелкнуть параметр по умолчанию Объединить запрос на вытягивание в экземпляр GitHub Enterprise Server, все фиксации из ветвь компонента добавляются в базовая ветвь в фиксации слияния. Запрос на вытягивание объединяется с помощью параметра --no-ff.

Чтобы объединить запросы на вытягивание, необходимо иметь разрешения на запись в репозиторий.

Метод слияния по умолчанию создает фиксацию слияния. Вы можете запретить любому пользователю принудительно отправлять фиксации слиянием в защищенную ветвь, применяя журнал линейной фиксации. Дополнительные сведения см. в разделе Сведения о защищенных ветвях.

Сжатие фиксаций слиянием

При выборе параметра Squash и merge в запросе на вытягивание в экземпляр GitHub Enterprise Server фиксации запроса на вытягивание сдавляются в одну фиксацию. Вместо просмотра всех отдельных фиксаций участника из ветви раздела фиксации объединяются в одну фиксацию, а также выполняется их слияние в ветвь по умолчанию. Запросы на вытягивание со сжатыми фиксациями объединяются с помощью параметра перемотки вперед.

Для слияния со сжатием запросов на вытягивание необходимо иметь разрешения на запись в репозитории, а для репозитория должно быть разрешено слияние со сжатием.

Для создания оптимизированного журнала Git в репозитории можно использовать слияние со сжатием. Фиксации, выполняемые в процессе работы, удобны при работе с ветвью компонентов, но они могут быть не важны для сохранения в журнале Git. Если при слиянии в ветвь по умолчанию эти фиксации будут сжаты в одну фиксацию, вы можете сохранить исходные изменения в четком журнале Git.

Прежде чем включать сжатие фиксаций, учтите следующие недостатки:

• Вы теряете сведения о том, когда конкретные изменения были внесены первоначально и кто создал сжатые фиксации.
• Если вы продолжите работу с головной ветвью запроса на вытягивание после сжатия и объединения, а затем создадите новый запрос на вытягивание между теми же ветвями, фиксации, которые вы ранее сжали и объединили, будут перечислены в новом запросе на вытягивание. Кроме того, в каждом последующем запросе на вытягивание могут возникать конфликты, которые необходимо будет каждый раз разрешать. Дополнительные сведения см. в разделе Сведения о слиянии запросов на вытягивание.
• Некоторые команды Git, использующие идентификатор SHA или hash, может быть сложнее использовать, так как идентификатор SHA для исходных фиксаций будет потерян. Например, использование git rerere может оказаться не столь эффективным.

Дополнительные сведения см. в разделе Настройка сжатия фиксаций для запросов на вытягивание.

Перемещение фиксации из одной ветви в другую и слияние

При выборе параметра Перебазировать и объединить в запросе на вытягивание в экземпляр GitHub Enterprise Server все фиксации из ветви раздела (или головной ветви) добавляются в базовую ветвь по отдельности без фиксации слиянием. Таким образом, поведение перебазирования и объединения напоминает объединение с перемоткой вперед путем сохранения журнала линейных проектов. Однако повторное размещение достигается путем повторной записи журнала фиксаций в базовой ветви с новыми фиксациями.

Поведение повторного размещения и объединения для GitHub Enterprise Server немного отклоняется от git rebase. Повторное создание и объединение в GitHub всегда обновляет сведения об авторе фиксации и создает новые фиксации SHA, тогда как git rebase за пределами GitHub не изменяет сведения об авторе фиксации при повторном размещении поверх фиксации предка. Дополнительные сведения о процессе git rebase см. в разделе git-rebase в документации Git.

Для повторного размещения с объединением запросов на вытягивание необходимо иметь разрешения на запись в репозитории, а для репозитория должно быть разрешено слияние со сжатием.

Визуальное представление git rebase см. в разделе "Ветвление Git. Повторное размещение" из _книги_Pro Git.

Перед включением перемещения фиксации из одной ветви в другую, рассмотрите следующие недостатки:

• Участникам репозитория может потребоваться перебазироваться в командной строке, устранить конфликты и принудительно отправить изменения в раздел запроса на вытягивание (или в удаленную головную ветвь), прежде чем они смогут использовать параметр перебазировать и объединить в экземпляр GitHub Enterprise Server. Следует проявлять осторожность при отправке с параметром --force, чтобы не перезаписать работу, на основе которой работают другие пользователи. Дополнительные сведения о том, когда параметр Перебазировать и объединить отключен в экземпляр GitHub Enterprise Server и рабочем процессе для его повторного включения, см. в разделе Сведения о слиянии запросов на вытягивание.

• При использовании варианта Перемещение и слияние для запроса на вытягивание важно помнить, что фиксации в головной ветви добавляются в базовую ветвь без проверки подписи фиксации. При использовании этого варианта GitHub создает измененную фиксацию, используя данные и содержимое исходной фиксации. Это означает, что GitHub не создает новую фиксацию и не может подписать ее как обычный пользователь системы. GitHub не имеет доступа к закрытым ключам для подписывания этой фиксации, поэтому не может подписать фиксацию от имени пользователя.

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

Дополнительные сведения см. в разделе Настройка перемещения фиксаций между ветвями для запросов на вытягивание.