Форкинг против Ветвления в GitHub - PullRequest
Новая
       11

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

252 голосов
/ 31 августа 2010

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

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

Ответы [ 4 ]

262 голосов
/ 31 августа 2010

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

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

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

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

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

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

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

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

fork on GitHub

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

См. также:

62 голосов
/ 17 декабря 2015

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

Форкинг

Плюсы

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

Минусы

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

Ветвление

Плюсы

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

Минусами

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

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

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

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

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

2 голосов
/ 01 марта 2018

Форкинг создает совершенно новый репозиторий из существующего репозитория (просто делая 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

...