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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

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

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

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

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

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

Ответ 10

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

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

а также

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