Skip to main content

Enterprise Server 3.15 в настоящее время доступен в качестве кандидата на выпуск.

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

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

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

Note

При использовании очереди слияния вы больше не можете выбрать метод слияния, так как это контролируется очередью. Дополнительные сведения о очередях слиянием см. в разделе "Управление очередью слияния".

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

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

Схема стандартного потока слияния и фиксации, где фиксации из ветвь компонента и дополнительной фиксации слияния добавляются в "main".

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

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

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

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

Схема скваширования фиксации, в которой несколько фиксаций из ветвь компонента объединяются только в одну фиксацию, которая добавляется в "main".

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

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

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

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

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

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

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

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

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

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

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

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