Являются ли Git-вилки Git-клонами?


817

Я продолжаю слышать, как люди говорят, что они раздувают код в Git. Git "fork" звучит подозрительно, как Git "clone" плюс некоторая (бессмысленная) психологическая готовность отказаться от будущих слияний. В Git нет команды fork, верно?

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

Да нет? Есть опасения, что GitHub расширяет Git в этом направлении? Или какие-нибудь слухи о поглощении Git функциональности?


10
Да, это просто тип клона, который отслеживается базой данных github.
Пауло Эберманн

15
Разве GitHub не делает что-то особенное, чтобы избежать удвоения требований к хранилищу (на собственных серверах GitHub)?
Кит Томпсон

18
Пока не упомянуто: удаление частного репо удаляет все его вилки. Удаление публичного репо сохраняет вилки, но продвигает один форк в качестве нового родительского репо. Если ваш босс делает ваше публичное репо приватным, он ломает все существующие вилки, и вы не сможете делать запросы от них на частное репо. help.github.com/articles/…
Платон

Я считаю (без доказательств, поскольку GitHub не показывает это нам), что фактический механизм здесь - это «альтернативы» Git. Другими словами, вилка является зеркальным клоном с --referenceкрестиком. Как именно обрабатываются публичные репо и удаления, не совсем понятно (переместить альтернативы в произвольно выбранные продвигаемые репо - указать все вилки на какой-нибудь общий альтернативный вариант, не являющийся частью исходного форка?), Но использование альтернатив объясняет различные наблюдаемые варианты поведения.
Торек

Ответы:


925

В контексте GitHub Fork не расширяет Git.
Это позволяет только клонировать на стороне сервера.

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

  • клонируйте этот репозиторий GitHub на свою учетную запись GitHub (то есть часть "fork" , клон на стороне сервера)
  • добавить коммиты в этот репозиторий GitHub (он находится в вашей собственной учетной записи GitHub, поэтому вы имеете полное право на него)
  • сообщать о любом интересном вкладе в исходный репозиторий GitHub (это часть «запроса на извлечение» посредством изменений, которые вы внесли в свой собственный репозиторий GitHub)

Проверьте также « Совместная работа GitHub ».

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

вилка и вверх по течению

А с Git 2.20 (Q4 2018) и более, выборка с вилки более эффективна, с дельта-островами .


6
«Когда вы клонируете репозиторий GitHub на своей локальной рабочей станции, вы не можете внести свой вклад в репозиторий верхнего уровня, если вы явно не объявлены как« участник »». --- Разве это не правда с "разветвлением"? Пожалуйста, объясни.
Чарви

61
@ TestSubject528491 нет, с вилкой, это означает, что вы клонируете обратное репо как свое собственное репо на стороне сервера GitHub. Затем вы можете локально клонировать этот новый репозиторий «fork» на своем компьютере и свободно перемещать его обратно, поскольку вы являетесь создателем и владельцем этого форка.
VonC

9
Для меня ключевой момент заключается в том, что вы не можете отправить PR из своей локальной копии, если вы не заявили о своем участии . Я так привык подавать PR из моего локального репо, но это потому, что я всегда отмечен как участник. Если вы думаете об этом, чтобы отправить PR, вы должны нажать ветку на удаленное хранилище, а затем создать PR. Я думаю, это имеет смысл, если вы не хотите, чтобы случайные люди создавали ветки в вашем репо. И что вы предпочли бы, чтобы они раскошелились и подали PR таким образом.
Адам Зернер

Я видел второй «восходящий» удаленный подход в другом месте, но не проще ли перенести напрямую из «GitHub-Original» в «GitHub-Fork»? Второй удаленный подход, похоже, не сработал в моей настройке Eclipse и eGit, так как мне не удалось перейти к моему репозиторию «GitHub - Fork» (ничего не выдвинуть).
Уильям Т. Маллард

Не берите в голову, ссылка информации здесь дала мне некоторое понимание. В качестве соавтора имеет смысл перейти с «GitHub-Original» на «GitHub-Fork», затем с «-Fork» на локальную машину, но если вы владелец, вы, вероятно, захотите вытащить напрямую из моей «-Fork» сначала просмотрите, запустите тесты и т. д., прежде чем нажать «- Оригинал».
Уильям Т. Маллард

135

Я продолжаю слышать, как люди говорят, что они раздувают код в git. Git "fork" звучит подозрительно, как git "clone" плюс некоторая (бессмысленная) психологическая готовность отказаться от будущих слияний. В git нет команды fork, верно?

«Форкинг» - это концепция, а не команда, специально поддерживаемая любой системой контроля версий.

Самый простой вид разветвления является синонимом ветвления. Каждый раз, когда вы создаете ветку, независимо от вашей VCS, вы «разветвляетесь». Эти вилки обычно довольно легко объединить.

Разветвление, о котором вы говорите, когда отдельная сторона берет полную копию кода и уходит, обязательно происходит за пределами VCS в централизованной системе, такой как Subversion. Распределенная VCS, такая как Git, имеет гораздо лучшую поддержку для разветвления всей кодовой базы и эффективного запуска нового проекта.

Git (не GitHub) изначально поддерживает «разветвление» всего репо (т.е. его клонирование) несколькими способами:

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

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

Есть ли опасения по поводу Github, расширяющего git в этом направлении? Или какие-нибудь слухи о том, что Git поглощает функциональность?

Там нет страха, потому что ваше предположение неверно. GitHub «расширяет» функциональность разветвления Git с помощью приятного графического интерфейса и стандартизированного способа выдачи запросов извлечения, но не добавляет функциональности в Git. Концепция полного репо-форкинг заложена прямо в распределенном контроле версий на фундаментальном уровне. Вы можете отказаться от GitHub в любой момент и при этом продолжать продвигать / извлекать проекты, которые вы «разветвляли».


6
Спасибо за ваш отличный ответ. Я просто хочу уточнить, это означает, что вне контекста GitHub я мог бы клонировать некоторые X projectна моей машине. Если я внесу изменения в свой локальный сайт и не имею права на запись в источник, я напишу автору проекта письмо с просьбой о проведении проверки. Он сделает пульт под названием Гидеон, который будет URL моего локального клона, и он может тянуть, верно?
Гидеон

1
Если вы хотите внести свои изменения в проект, вы можете либо сохранить их в файлы, например, с помощью git format-patch и прикрепить их к электронному письму тому, кто имеет такой доступ для записи, либо вы можете получить собственный хостинг, перенести свою работу на это и отправьте URL в электронном письме, например, используя команду git request-pull. Репо на рабочих станциях обычно не доступны в Интернете.
BDSL

Но да, если ваша рабочая станция оказывается доступной через Интернет для автора проекта, то вы можете просто отправить им URL-адрес, и они могут добавить его как удаленный и извлечь из него.
BDSL

1
Re: angst, единственное, что мне нужно, это то, что нет никакой ссылки или кнопки, чтобы щелкнуть, чтобы создать кнопку перспективы извлечения из моего репо, где GitHub сообщает вам, что вы на 50 коммитов позади. Не важно, теперь, когда я знаю, что они используют термин «запрос на извлечение», чтобы также включать запросы на получение от верхнего уровня до вашего форка GitHub. Git это сложно.
Уильям Т. Маллард

80

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

В будущем, если фактический владелец или другие пользователи с вилкой, как ваши изменения, они могут вернуть его в свой собственный репозиторий. В качестве альтернативы вы можете отправить им «pull-request».


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

4
@Casey Вы можете отправить запрос на извлечение через GitHub только от самого GitHub, а вы можете отправить только запрос на GitHub из ветки, существующей на GitHub. Если вы не являетесь соавтором рассматриваемого репозитория, у вас нет возможности создать ветку, из которой вы можете инициировать пул-запрос GitHub. Ничто не мешает вам делать это по электронной почте по старинке, но GitHub не играет в этом никакой роли.
Бо Сименсен

2
@Casey, причина в том, что обычно другие не имеют доступа URL к вашей рабочей станции. GitHub forkозначает, что на вашем сервере GitHub есть копия вашей работы, к которой вы можете pushобращаться, и к которой другие имеют доступ по URL, чтобы они могли pull. Это pull requestпросто стандартный способ получения URL-адреса вашей копии (на GitHub), чтобы они могли легко перенести его в свой репозиторий.
Джесси Чисхолм

Это должен быть правильный / принятый ответ, я верю. Представьте себе беспорядок в сцене, где команда из 15-20 разработчиков, создающих ветви и подталкивающих к исходному, против 15-20 разработчиков, имеющих собственную копию одного и того же хранилища и создающих как можно больше ветвей, вносящих изменения и отталкивающих их назад. Тогда Автор оригинального репозитория может извлекать только те изменения, которые он / она хочет.
Кишор Павар

37

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


2
В частности: «Сделайте копию своего кода, on the GitHub serverчтобы я мог добавлять свои собственные модификации and others can have URL access to my version». Большинство локальных рабочих станций не предоставляют доступ к URL-адресам для тех, кто может их использовать. Но если вы нажмете на свою вилку на сервере, тогда у них может быть URL для получения.
Джесси Чисхолм

Вопрос не о разветвлении вообще, а о разветвлении GitHub конкретно.
reinierpost

26

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


11

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

Git clone - это настоящая команда, которая позволяет пользователям получить копию исходного кода. git clone [URL] Это должно создать копию [URL] в вашем локальном хранилище.


10

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


10

Здесь есть недоразумение относительно того, что такое «вилка». На самом деле, ответвление - это не что иное, как набор веток для каждого пользователя. Когда вы нажимаете на разветвление, вы действительно продвигаетесь в исходное хранилище, потому что это ЕДИНСТВЕННОЕ хранилище.

Вы можете попробовать это, нажав на форк, отметив коммит, а затем перейдя в исходный репозиторий и используя идентификатор коммита, вы увидите, что коммит находится «в» исходном репозитории.

Это имеет большой смысл, но это далеко не очевидно (я обнаружил это только недавно).

Когда Джон разветвляет репозиторий SuperProject, кажется, что на самом деле все ветки в исходном репозитории реплицируются с такими именами, как «John.master», «John.new_gui_project» и т. Д.

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

Так что ветвь моей ветки "master" на самом деле называется "Korporal.master", но пользовательский интерфейс GitHub никогда не раскрывает это, показывая мне только "master".

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

По этой причине я думаю, что для Microsoft было бы очень легко внедрить вилки Git в свои предложения Visual Studio Team Services.


Уважаемый Хью, половина вашего ответа на самом деле неверна - форк - это клон целого хранилища из одной учетной записи в другую, вместе со всеми ветками и историей. Когда вы фиксируете форк, ничего не меняется в исходном репозитории, из которого вы разветвлены. Но помимо этих нескольких недоразумений с вашей стороны относительно того, что такое «форк», теперь есть и хорошие новости: сервисы Visual Studio Team теперь включают функциональность «Fork». ;)
Сорин Постельнику

1
@SorinPostelnicu источник? Я склонен верить Хью здесь из-за личного опыта вилок, которые ведут себя не так, как простой клон репозитория. Например, когда удаляется восходящий поток, удаляются вилки (как было упомянуто в комментарии к вопросу OP), и иногда восходящий поток приводил к объединению вещей в ветви моих вилок при приеме запроса на извлечение без моего участия.
картофель

Действительно, похоже, это так. В конце концов, для GitHub было бы невероятно глупо буквально создавать git cloneцелый новый репозиторий (даже «пустой») каждый раз, когда кто-то нажимает кнопку «fork» - это было бы невероятной тратой памяти и, вероятно, вектором атаки. ,
Грег А. Вудс

7

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

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

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

Форк не является командой в Git; это просто концепция, которую реализует GitHub. Помните, что Git был разработан для работы в одноранговой среде без необходимости синхронизировать материал с какой-либо мастер-копией. Сервер - это просто еще один узел, но мы рассматриваем его как мастер-копию.


7
А? Вилка получает все ветви, хотя вы должны знать, где искать (подсказка git branch -a).
tripleee

3

Проще говоря,

Когда вы говорите, что разветвляете хранилище, вы в основном создаете копию исходного хранилища под своим идентификатором GitHub в своей учетной записи GitHub.

а также

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.