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

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

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

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

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

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

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

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

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

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

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

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

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

• Мерзавец вилка это мерзавец клон?
• Вытащите новые обновления из исходного репозитория Github в разветвленный репозиторий Github.

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

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

Pros

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

Cons

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

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

Pros

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

Cons

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

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

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

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

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

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