Чи справді Git-вилки є клонами Git?

817

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

GitHub робить вилки трохи реальнішими, з'єднуючи кореспонденцію на ній. Тобто ви натискаєте кнопку виделки і пізніше, коли ви натискаєте кнопку запиту на виклик, система досить розумна, щоб надіслати електронною поштою власнику. Отже, це трохи танець навколо власності та прав доступу до сховища.

Так ні? Будь-який приступ над GitHub, що розширює Git у цьому напрямку? Або якісь чутки про Git поглинають функціональність?

— Брайан
джерело

10

Так, це просто тип клону, який відстежується базами даних github.

— Paŭlo Ebermann

15

Чи GitHub не робить щось особливе, щоб уникнути подвоєння вимог зберігання (на власних серверах GitHub)?

— Кіт Томпсон

18

Ще не згадується: Видалення приватного репо видаляє всі його вилки. Видалення загальнодоступного репо зберігає вилки, але сприяє тому, щоб одна вилка була новою батьківською репо. Якщо ваш начальник зробить ваше публічне репо-приватне приватним, воно розбиває всі існуючі вилки, і ви не зможете робити запити на тягнення з них до приватного репо. help.github.com/articles/…

— Платон

Я вважаю (без доказів, оскільки GitHub нам цього не демонструє), що власне механізмом тут є "чергування" Гіта. Іншими словами, виделка - це дзеркальний клон із --referenceвикористаним. Точно, як обробляються публічні репозиції та видалення, зовсім не зрозуміло (переміщуйте чергування на випадково вибране рекламоване репо? Вказівка всіх вил на якийсь загальний альтернативний варіант, який не є частиною оригінальної вилки?), Але використання альтернативних пояснює різні види поведінки, що спостерігаються.

— Торека

925

Gel , в контексті GitHub, не поширює Git.
Це дозволяє лише клонувати на стороні сервера.

Коли ви клонуєте сховище GitHub на локальній робочій станції, ви не можете внести свій внесок у сховище вище, якщо ви не будете явно оголошені як "учасник". Це тому, що ваш клон - це окремий екземпляр цього проекту. Якщо ви хочете внести свій внесок у проект, ви можете використовувати forking для цього наступним чином:

клонуйте цей сховище GitHub у вашому обліковому записі GitHub (тобто частина "fork" , клон на стороні сервера)
внести зобов’язання у цей сховище GitHub (він знаходиться у вашому власному обліковому записі GitHub, тому ви маєте повне право перейти до нього)
подати сигнал про будь-який цікавий внесок до оригінального сховища GitHub (тобто частини "запиту на витяг" за допомогою змін, які ви внесли у власне сховище GitHub)

Перевірте також " Спільний робочий процес GitHub ".

Якщо ви хочете зберегти посилання з оригінальним сховищем (його також називають висхідним сховищем), вам потрібно додати віддалене посилання на це оригінальне сховище.
Див. " Яка різниця між початком та потоком на GitHub? "

вила та вище за течією

А з Git 2.20 (Q4 2018) та більше, витяг із вилки є більш ефективним, з островами дельти .

— VonC
джерело

6

"Коли ви клонуєте репортаж GitHub на вашій локальній робочій станції, ви не можете внести свій внесок у репортаж вище, за винятком випадків, якщо ви явно не оголошені як" учасник "." --- Невже це не так з "розщепленням"? Будь ласка, поясніть.

— chharvey

61

@ TestSubject528491 ні, з виделкою, це означає, що ви клонуєте репо-версію за потоком як своє власне репо на стороні сервера GitHub. Тоді ви можете локально клонувати цю нову репо "вилку" на своєму комп’ютері та вільно відштовхуватися на ній, оскільки ви творець та власник цієї вилки.

— 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, правда?

"Forking" - це концепція, а не команда, яка спеціально підтримується будь-якою системою управління версіями.

Найпростіший вид розгалуження - синонім розгалуження. Кожен раз, коли ви створюєте відділення, незалежно від свого VCS, ви "розщедрилися". Такі виделки зазвичай досить легко з'єднати назад.

Такий вид вила, про який ви говорите, де окрема сторона бере повну копію коду і відходить, обов'язково відбувається поза VCS в централізованій системі, як Subversion. Розподілений VCS на зразок Git має набагато кращу підтримку для розгортання всієї кодової бази та ефективного запуску нового проекту.

Git (не GitHub) споконвічно підтримує "форкінг" цілого репо (тобто клонування) двома способами:

коли ви клонуєте, originдля вас створюється віддалений дзвінок
за замовчуванням всі гілки в клоні будуть відслідковувати їх origin еквіваленти
вилучення та злиття змін з оригінального проекту, від якого ви роздвоялися, надзвичайно просто

Git робить внесені зміни назад до джерела виделки настільки ж простими, як і прохання когось із оригінального проекту відійти від вас, або запит на доступ до запису, щоб відштовхувати зміни назад. Це частина, яку GitHub робить простішою і стандартизує.

Будь-який приступ над Github, що розширює git у цьому напрямку? Або чутки про git, що поглинають функціональність?

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

— мегагар
джерело

6

Дякую за відмінну відповідь. Я просто хочу уточнити, це означає, що поза контекстом github я міг би клонувати їх X projectна своїй машині. Якщо я внесу зміни у свій локальний і не маю доступу для запису до походження, я надішлю електронний лист автору проекту, щоб надіслати запит на перенесення. Він зробить віддалений під назвою гедеон, який буде URL для мого місцевого клона, і він може витягнути, правда?

— gideon

1

Якщо ви хочете внести свої зміни в проект, ви можете або зберегти їх у файли, наприклад, використовуючи git-патч-формат і приєднати їх до електронного листа тому, хто має доступ до запису, або ви можете отримати власний хостинг, підштовхніть свою роботу до цього і надішліть URL-адресу електронною поштою, наприклад, використовуючи команду git request-pull. Робочі повідомлення на робочих станціях зазвичай не доступні в режимі онлайн.

— bdsl

Але так, якщо ваша робоча станція буде доступна автору проекту через Інтернет, то ви можете просто надіслати їм URL, і вони можуть додати її як віддалений та витягнути з нього.

— bdsl

1

Re: angst, єдиним для мене є те, що немає жодного посилання або кнопки, щоб натиснути, щоб створити кнопку "pers-from-my-repo" в перспективі, де GitHub повідомляє, що ти відстаєш на 50. Зараз я не знаю, що вони використовують термін "Затягнути запит", щоб також включити запити на витяг з вищого потоку на вашу вилку GitHub. Гіт важкий.

— Вільям Т. Маллард

80

Так, виделка - це клон. Він з’явився тому, що без їх дозволу ви не можете натискати на чужі копії . Вони роблять для вас його копію ( виделка ), де ви також матимете дозвіл на запис.

Надалі, якщо фактичний власник або інші користувачі з виделкою, як ваші зміни, вони можуть повернути його до власного сховища. Крім того, ви можете надіслати їм "тягнути запит".

— ссапкота
джерело

Чи можу я просто клонувати сховище до своєї локальної машини, створити відділення, а потім подати запит на витяг до початкового власника? Мабуть, зайвим є наявність декількох копій репостів, які розміщені по всьому GitHub, просто для полегшення оновлення коду.

— Кейсі

4

@Casey Ви можете надіслати запит на притягнення лише через GitHub від самого GitHub, а ви можете надіслати запит на тягу лише GitHub із гілки, яка існує на GitHub. Якщо ви не є співробітником відповідного сховища, у вас немає способу створити гілку, з якої можна ініціювати запит на витяг GitHub. Ніщо не заважає вам робити це електронною поштою старомодним способом, але GitHub не грає в цьому жодної ролі.

— Beau Simensen

2

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

— Джессі Чисгольм

Це я повинна бути правильною / прийнятою відповіддю. Уявіть безлад у сцені, коли команда з 15-20 розробників створює гілки та підштовхує до походження проти 15-20 розробників, які мають власну копію того ж сховища та роблять стільки гілок та роблять зміни та відштовхують її назад. Тоді автор оригінального сховища може витягувати лише ті зміни, які він хоче.

— Кішор Павар

37

"Fork" в цьому контексті означає "Зробіть копію їх коду, щоб я міг додати свої зміни". Ще багато чого сказати. Кожен клон, по суті, є виделкою, і вирішити, чи потрібно витягувати зміни з виделки, вирішуватиметься оригінал.

— Даєніт
джерело

2

Зокрема: "Зробіть копію свого коду, on the GitHub serverщоб я міг додати свої зміни and others can have URL access to my version". Більшість місцевих робочих станцій не пропонують доступ до URL для тих, хто має змогу витягнути. Але якщо ви наштовхнетесь на свою розкрутку на сервері, вони можуть мати URL-адресу для витягування.

— Джессі Чисгольм

Питання не в тому, щоб розщедритися взагалі, а конкретно про розгортання GitHub.

— reinierpost

26

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

— Сем Джонсон
джерело

11

Форкінг робиться, коли ви вирішили внести свій внесок у якийсь проект. Ви б зробили копію всього проекту разом з журналами його історії. Ця копія повністю створена у вашому сховищі, і як тільки ви внесете ці зміни, ви надсилаєте запит на витяг. Тепер власник джерела повинен прийняти ваш запит на притягнення та включити зміни до оригінального коду.

Клон Git - це фактична команда, яка дозволяє користувачам отримати копію джерела. git clone [URL] Це має створити копію [URL] у вашому власному локальному сховищі.

— aliasav
джерело

10

Я думаю, що форк - це копія іншого сховища, але з модифікацією вашого акаунта. наприклад, якщо ви локально клонуєте інше сховище локально, віддалене походження об’єкта все ще використовує обліковий запис, з якого ви клонуєте. Ви не можете ввести і внести свій код. Це просто чиста копія кодів. В іншому випадку, якщо ви розкладете сховище, воно буде клонувати репо з оновленням налаштування вашого акаунта у вашому обліковому записі github. А потім клонувавши репо в контексті вашого акаунта, ви можете ввести свої коди.

— Даніель Шен
джерело

10

Тут виникає непорозуміння щодо того, що таке "виделка". Вилка насправді - це не що інше, як набір гілок кожного користувача. Коли ви натискаєте на вилку, ви насправді натискаєте на оригінальний сховище, тому що це ТОЛЬКО сховище.

Ви можете спробувати це, натиснувши на вилку, помітивши фіксацію, а потім перейшовши до оригінального сховища та використовуючи ідентифікатор фіксації, ви побачите, що фіксація "знаходиться" в початковому сховищі.

Це має багато сенсу, але це далеко не очевидно (я це відкрив лише випадково недавно).

Коли Джон forks сховище SuperProject, здається, що насправді це відбувається, це те, що всі гілки у вихідному сховищі реплікуються з назвою на зразок "John.master", "John.new_gui_project" тощо.

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

Так гілка моєї вилки "майстер" насправді називається "Korporal.master", але інтерфейс GitHub ніколи цього не розкриває, показуючи мені лише "майстра".

Це майже все, що, на мою думку, продовжується під кришкою на основі речей, які я робив останнім часом, і коли ви розмірковуєте над цим, це дуже хороший дизайн.

З цієї причини я думаю, що Microsoft буде дуже легко реалізувати Git forks у своїй програмі служб Visual Studio Team Services.

— Х'ю
джерело

Шановний Х'ю, половина вашої відповіді насправді неправильна - вилка - це клон цілого сховища від одного облікового запису користувача до іншого облікового запису, разом із усіма гілками та історією. Коли ви переходите на вилку, нічого не змінюється в оригінальному сховищі, з якого ви розщелилися. Але окрім цих кількох непорозумінь з вашого боку щодо того, що таке «вилка», зараз є і хороша новина: Служби Visual Studio Team тепер включають функцію «Fork». ;)

— Сорін Постельніку

1

@SorinPostelnicu джерело? Я схильний вважати, що тут Х'ю завдяки особистому досвіду роботи вил, що поводяться непослідовно, оскільки вони є простим клоном сховища. Наприклад, коли видаляється висхідний потік, вилки видаляються (як це було сказано в коментарі до питання ОП), а іноді вгору за течією згортаються об'єднання речей у гілки моїх вил при прийнятті запиту на витягнення, не роблячи нічого.

— картопля

Дійсно, це так і є. Зрештою, для GitHub було би неймовірно нерозумно буквально git cloneцілком нове сховище (навіть «оголене») кожного разу, коли хтось натискає кнопку «виделки» - це було б неймовірною тратою зберігання та, ймовірно, вектором нападу .

— Грег А. Вудс

7

Крім того, що клонування відбувається від сервера до вашої машини і розгортання робить копію на самому сервері, важлива різниця полягає в тому, що коли ми клонуємо, ми фактично отримуємо всі гілки, мітки тощо.

Але коли ми розщеплюємось, ми фактично отримуємо лише поточні файли у головній гілці, нічого іншого, крім цього. Це означає, що ми не отримуємо інших гілок тощо.

Отже, якщо вам доведеться щось об'єднати з початковим сховищем, це злиття між репозиторіями і, безумовно, потрібні більш високі привілеї.

Fork - це не команда в Git; це лише концепція, яку реалізує GitHub. Пам'ятайте, що Git був розроблений для роботи в одноранговому середовищі без необхідності синхронізувати матеріали з будь-якою головною копією. Сервер - це лише інший аналог, але ми розглядаємо це як основну копію.

— Діпак Г.М.
джерело

7

Так? Вилка отримує всі гілки, хоча ви повинні знати, де шукати (підказка:) git branch -a.

— трійка

3

Найпростіше кажучи,

Коли ви кажете, що ви роздвоєні сховище, ви в основному створюєте копію оригінального сховища під вашим ідентифікатором GitHub у своєму обліковому записі GitHub.

і

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

— anoNewb
джерело