Форкинг против ветвления в GitHub

278

Я хотел бы узнать больше о преимуществах и недостатках разветвления проекта github по сравнению с созданием ветви проекта github.

Форкинг делает мою версию проекта более изолированной от первоначальной, потому что мне не нужно быть в списке соавторов исходного проекта. Поскольку мы разрабатываем собственный проект, нет проблем с добавлением людей в качестве соавторов. Но мы хотели бы понять, не затруднит ли разветвление проекта изменения основного проекта. То есть мне интересно, облегчает ли ветвление синхронизацию двух проектов. Другими словами, легче ли объединять и передавать изменения между моей версией основного проекта и основным проектом, когда я ветвлюсь?

git branch github

— Reprogrammer
источник

280

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

Форкинг - это не что иное, как клон на стороне сервера GitHub :

без возможности прямого отталкивания
с очередью вилки добавлена функция управления запросом слияния

Вы поддерживаете синхронизацию с оригинальным проектом:

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

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

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

Тот факт, что вы клонируете на стороне GitHub, означает, что у вас теперь есть два «центральных» хранилища («центральное» как «видимое от нескольких соавторов).
Если вы можете добавить их непосредственно как соавтор для одного проекта, вам не нужно управлять другим один с вилкой.

форк на GitHub

Опыт слияния будет примерно таким же, но с дополнительным уровнем косвенности (сначала нажмите на развилку, затем попросите вытянуть, с риском эволюции на исходном репо, из-за чего ваши слияния с ускоренной перемоткой больше не будут перемотать вперед) ,
Это означает, что правильным рабочим процессом является git pull --rebase upstream(перебазировать вашу работу поверх новых коммитов из апстрима), а затем git push --force origin, чтобы переписать историю таким образом, чтобы ваши собственные коммиты всегда были поверх коммитов из исходного (восходящего) репо ,

Смотрите также:

— VonC
источник

3

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

— репрограммист

7

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

— VonC

14

Честно говоря, даже если вам не нужно, всегда полезно иметь священное репо, доступное для записи только для старших разработчиков, руководителей команд или других «доверенных» людей . Все остальные члены команды должны работать в своих вилках (~ песочницах) и вносить свои изменения в форме запроса на извлечение. Поскольку DVCS делает это возможным, мы адаптировали его как «лучшую практику» и успешно используем его даже в самых маленьких проектах ...

— Intland

1

@intland, так что вы больше поддерживаете «рабочий процесс менеджера интеграции», как описано в stackoverflow.com/users/6309/vonc?tab=responses затем? Для того, чтобы внедрить Git в большой корпорации, я склонен сначала принять централизованный рабочий процесс (более знакомый для всех), прежде чем перейти к «Менеджеру интеграции».

— VonC

15

Мы должны называть вилки "ветками", так как они разорваны на ветке и используются для создания нового дерева. Просто мои два цента - мне нравится древесная идиома.

— Эрик

67

Вот различия высокого уровня:

Разветвление

Pros

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

Cons

Делает более трудным видеть все ветви, которые активны (или неактивны, в этом отношении)
Совместная работа над веткой сложнее (владелец ветки должен добавить человека в качестве соавтора)
Вам нужно понять концепцию нескольких пультов в Git
- Требуется дополнительная психическая бухгалтерия
- Это сделает рабочий процесс более трудным для людей, которые не очень удобны с Git

разветвление

Pros

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

Cons

Заброшенные ветки могут накапливаться легче
Процесс участия вашей команды не соответствует процессу внешнего участника
Вы должны добавить членов команды в качестве участников, прежде чем они смогут переходить

— Эйдан Фельдман
источник

Что подразумевается под «процессом внешнего участника»?

— Карс Барендрехт

1

@KarsBarendrecht Обновлено, чтобы использовать термин «внешний участник». Кто-то, у кого нет writeразрешений на хранилище.

— Эйдан Фельдман

45

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

Общая схема выглядит следующим образом:

Создайте репозиторий исходного проекта, чтобы иметь собственную копию GitHub, в которую вам затем будет разрешено вносить изменения.
Клонируйте свой репозиторий GitHub на свой локальный компьютер
При желании добавьте исходный репозиторий в качестве дополнительного удаленного репозитория в локальный репозиторий. После этого вы сможете получать изменения, опубликованные в этом хранилище напрямую.
Вносите свои изменения и свои коммиты локально.
Внесите изменения в репозиторий GitHub (поскольку у вас обычно не будет прав на запись в репозиторий проекта напрямую).
Свяжитесь с сопровождающими проекта и попросите их загрузить ваши изменения и просмотреть / объединить, и пусть они вернутся в хранилище проекта (если вы и они захотите).

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

— Bruno
источник

@RecoJohnson, хорошо ... Я не использовал слово «тянуть» в своем ответе (но «тянуть» фактически означает «получить» + «объединить» в терминах Git). Какое использование «толчка» вы считаете неправильным?

— Бруно

2

@RecoJohnson Вы как участник толкаете на свою ветку GitHub; сопровождающие проекта извлекают ваш вклад из вашей вилки.

— mljrg

1

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

— code4cause

9

Forking создает совершенно новый репозиторий из существующего репозитория (просто делая git clone на gitHub / bitbucket)

Лучше всего использовать форки: когда целью «split» является создание логически независимого проекта, который никогда не сможет воссоединиться со своим родителем.

Стратегия ветвления создает новую ветвь поверх существующего / рабочего хранилища.

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

Более конкретно: - В проектах с открытым исходным кодом именно владелец хранилища решает, кто может отправить его в хранилище. Тем не менее, идея открытого исходного кода заключается в том, что каждый может внести свой вклад в проект.

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

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

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

https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/

https://buddy.works/blog/5-types-of-git-workflows

http://www.continuousagile.com/unblock/branching.html

— кто я
источник

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

— StriplingWarrior