Fork на GitHub — что это такое
September 05, 2014
Продолжаю увлекательное знакомство новичка с сервисом GitHub и с системой контроля версий Git.
Так как имею учетную запись на GitHub, которую регулярно использую, то у меня возник вопрос, который не мог не возникнуть, рано или поздно. Касается он такой темы, как fork.
Не знаю даже, как правильно поступить дальше — попытаться самому описать вопрос, своими словами; или же попытаться сделать вольный перевод статьи на эту тему — Fork A Repo. Но лучше все же расскажу своими словами.
Fork — это копия репозитория
Fork — это вcего навсего копия репозитория. Это тоже самое, что branch в Git. Только на GitHub такой branch называется fork — присутствует своя терминология. Само слово fork в переводе означает ответвление. Для того, чтобы воспользоваться fork , нужно иметь свою собственную учетную запись на GitHub; и нужно войти под ней на GitHub в момент выполнения fork .
Для чего нужен fork ? Для тех же целей, что и branch в Git. С помощью него создается точная копия оригинального репозитория, только на сервисе GitHub. В копии репозитория можно вносить свои собственные изменения, редактировать файлы или удалять директории.
Как только все изменения будут внесены, то можно поделиться ими — отправить авторам оригинального репозитория запрос на слияние вашего измененного репозитория с их оригинальным репозиторием. Такой запрос называется pull request .
Если авторам оригинального репозитория ваши изменения понравятся, то они могут внести их в свой собственый оригинальный репозиторий — принять запрос и выполнить слияние.
Существование fork полностью отвечает идеологии OpenSource и GitHub, в частности. Идеология OpenSource заключается в свободном обмене исходным кодом программ и fork однозначно помогает в этом деле. С помощью fork можно одним движением получить копию любого исходного кода, выложенного на GitHub в свободном доступе.
Fork — создание копии репозитория
Давайте от слов перейдем к делу и на практике выполним хотя бы один fork на GitHub. К слову сказать, в приведенной выше статье-оригинале Fork A Repo дается ссылка на репозиторий Spoon-Knife, созданный авторами статьи для учебных целей — научиться работать с fork на GitHub. Вы, уважаемый читатель, также можете свободно воспользоваться им для себя, чтобы научиться пользоваться fork.
Я воспользуюсь другим репозиторием, который выложен в свободном доступе достаточно известным верстальщиком Юрием Артюхом (akella). Ниже привожу шаги по созданию Fork на GitHub.
- захожу на GitHub под своей учетной записью
- перехожу по ссылке github/akella/sass, по которой расположен репозиторий akella/sass
Фактически, теперь я нахожусь в репозитории akella/sass пользователя akella (Юрий Артюх). Об этом красноречиво говорит надпись akella/sass в левом верхнем углу окна браузера. В правом верхнем углу окна браузера нахожу кнопку Fork.
И нажимаю на нее:
Может случиться, что вы, уважаемый читатель, ничего и не заметите. Но это не так на самом деле. Приглядитесь к “главной” надписи — она изменилась с akella/sass на gearmobile/sass ; а ниже мелким шрифтом еще — forked from akella/sass . Думаю, тут и говорить больше нечего — все и так понятно.
Теперь этот репозиторий мой — точнее, у меня теперь копия оригинального репозитория akella/sass . Я могу делать с ним все, что мне понадобиться — просто пользоваться или же вносить свои собственные изменения.
Если изменения мне покажутся существенными, то я могу отправить пользователю akella запрос на слияние pull request моего репозитория gearmobile/sass с его репозиторием akella/sass . Если пользователь akella посчитает эти изменения действительно существенными (с его точки зрения), то он может и принять мой запрос.
Я также могу удалить репозиторий gearmobile/sass, если в нем отпадет надобность. Надеюсь, вы хорошо помните, как удалять репозиторий на GitHub — “Как удалить репозиторий на GitHub”.
TypeScript — размеченные объединения
> Пользовательское объединение типов — что это и как можно использоватьПомимо объединения **примитивных** типов данных (например):<% high. … Continue reading
Источник
Git fork. Зачем нужны форки и как с ними работать
Как и в случае с ребейзом, с форками в гите я разобрался не сразу. Вроде ничего особенного там нет, это просто копия репозитория, но натыкаешься на какие-то подводные камни и не сразу понимаешь, как их обойти. Да и вообще, зачем нужны эти форки, тоже осознаешь не сразу. Когда врубаешься, все становится просто, ну это как всегда.
Я не сторонник подхода «чо тут не понимать, тупой штоле» и попробую рассказать человеческими словами, что вообще такое форки, зачем они нужны и как с ними работать. А вы оцените, как получилось. Синьор git девелоперам статья покажется банальщиной, но тем, кто еще не успел обрести такой титул, будет полезно.
Начнем с примера.
Ты работаешь в компании Company в какой-то команде и со своими ребятами пишешь код, например, блога вашего сайта. Рядом сидят ребята из другой команды, которые занимаются админкой. У каждой команды отдельный репозиторий, вы работаете и друг другу не мешаете.
Вам приходит задача — дать возможность разрешать или запрещать комментировать статьи блога отдельным пользователям. Сами вы это сделать не можете. Такие данные о пользователях хранятся не на вашей стороне, а у ребят, занимающихся админкой. У них есть списки пользователей и все данные по ним. А вы тянете эти данные по апи. Прямо микросервисы, все как положено.
Доступа к их репозиторию нет, поэтому идете договариваться. Обсуждаете вместе детали. Так, нужно завести поле в базе, какое-нибудь булево isAllowedComments, соответственно, подготовить миграцию, вывести это поле отдельной колонкой в таблице пользователей, там поставить чекбокс и уметь сохранять это в базу. А еще в апи, которое вы дергаете, нужно добавить в респонсе это самое поле. Вроде немного, ребята говорят, окей, через пару дней сделаем. И на самом деле делают, все хорошо.
Небольшие просьбы вроде этой появляются все чаще. То вам нужно накатить миграцию и разбанить всех пользователей, которые зарегались больше года назад. То в апи в респонсе вам понадобилось количество комментов пользователя. И каждый раз вы идете с такой мелочью к соседям и просите это сделать.
Рано или поздно ребятам из админки это надоедает, потому что у них хватает и своей работы. Они предлагают вам дать права на репозиторий и пробовать такие небольшие задачи делать самим. Говорят, мол, с такой фигней типа добавления поля в респонс вы и сами справитесь. Если что, зовите, поможем. Прав на пуш в мастер, конечно, никто не даст, но свои ветки создавайте и присылайте мердж-реквесты. Мы смотрим, если все хорошо, то мерджим в мастер и выкладываем в прод. Все довольны. И нам работы меньше, и вам не ждать, пока у нас руки дойдут до вашей задачи.
Вы с командой соглашаетесь. Ты клонируешь их репозиторий и пилишь фичи. Примерно так
Дальше идешь в битбакеты-гитхабы, в репозиторий админки, делаешь мердж-реквест и ждешь, когда его примут. Обычная схема. Мердж-реквест примерно везде делается одинаково: ищешь кнопку «Создать мердж-реквест» или пулл-реквест, выбираешь свою ветку, затем выбираешь, куда сливать (обычно уже по умолчанию будет мастер) и жмешь «Отправить».
Проходит пара месяцев. Ты случайно замечаешь в репозитории админки ветку petya/update-email. Спрашиваешь ребят из админки, а что за Петя вам коммитит? Те говорят, а, это чувак из отдела емейлов, мы им тоже доступ дали, как и вам. Они тоже приходили к нам по 3 раза в месяц, мы задолбались и теперь с ними работаем по вашей схеме. Ничего, все довольны.
Проходит год. Команд, которые работают по такой схеме, уже десяток. В репозитории появляются ветки
- vasya/blog-user-ban
- petya-ivanov/email_new_field
- email/migration
- blog/hotfix
- petrov/srochno-v-prod
Эти ветки множатся, мерджатся между собой и вообще живут своей жизнью. Называются они как попало, коммиты подписывают кто во что горазд, старые ветки не удаляются после мерджей. Надвигается хаос.
Конечно, ребятам из админки не очень нравится такой мусор в их репозитории. Сначала они пытаются с этим бороться и проводить разъяснительные работы. Пытаются рассказать о правилах приличия в их репозитории. Пишут доку и официальное письмо всем программистам, где все подробно рассказывают. Как именовать ветки, как подписывать коммиты, не забывать удалять старые ветки, не заводить лишние ветки без надобности и прочее.
Это дело хорошее, но бесполезное. В компании полсотни разрабов, у каждого своя команда и свои правила работы с репозиторием. Люди приходят и уходят, эти правила уже никто не помнит, да и всем пофигу, главное фичу сделать, чего там заморачиваться с ветками и коммитами. Пусть у команды админки об этом голова болит. Главное, у нас все хорошо, в своем командном проекте, потому что мы никого к себе не пускаем, ахаха. Поэтому и ветки красиво называются, и коммиты адекватно подписаны. Нас тут 5 человек работают, уж между собой-то договоримся.
А между тем в репозитории админки образуется все больший трэш. То злодеи опять пушат ветки с названиями не по ГОСТу, и тимлида бесят. То сам тимлид с похмелья выдал новому чуваку доступы на пуш в мастер, а тот на радостях запушил миграцию, которая пол-сайта уронила. То по ошибке смерджили petya/hotfix вместо vasya/hotfix. В общем весело всем, кроме ребят из админки.
И вот однажды что-то изменилось. Тебе понадобилось запилить новую фичу и ты привычно набиваешь
Опа, что за фигня? Пробуешь еще раз на всякий случай — снова rejected. Пишешь команде админки
- репца, привет, я чот запушить вам не могу, вы права сняли?
- привет, Петя, да, мы убрали права на пуш для всех не-членов нашей команды
- эээ, ну во-первых, я Вася, а во-вторых, как мне теперь делать?
- теперь все мердж-реквесты принимаются из форков
- окей, а на фига это надо? Все равно же в мастер нельзя было запушить, все и так через мердж-реквесты было.
- видишь ли, Вася, у нас тут столько народа, что мы уже не понимаем, кто Вася, а кто Петя, а кто вообще мимо проходил. И в ваших ветках мы тут просто тонем, git fetch невозможно сделать. Мы пытались донести до коллег, что это наш репозиторий и мы просим соблюдать простые правила работы с ним. Но народа много и все решили, что наш проект это помойка, в которой можно делать, что угодно. Все равно ж в мастер не попадет, а там разберутся. Ну и пара инцидентов с неправильно выданными правами. Да, наш косяк, но вас слишком много, чтобы за каждым уследить. Короче, форкайте репозиторий и резвитесь там, как хотите. А нам отправляйте только мердж-реквесты. Вам без разницы, а нам спокойней и в репозитории чище.
- окей, понятно
Понятно-то оно понятно, но ты с форками не работал. Ладно, думаешь, разберешься же, не тупой. Мердж-реквест что ли из форка не отправишь? К тому же ты читал git-scm и знаешь, что форк — это просто копия репозитория. Начинаешь разбираться.
Сначала идешь в гитхаб-битбакет и ищешь там в нужном репозитории кнопку Fork. Обычно она недалеко от кнопки clone. Жмешь на fork и для тебя создается проект. Если исходный был company/adminka.git, то твой будет примерно vasya/adminka.git. Ну или примерно так. Дальше клонируешь его как обычно
Естественно, свой форк клонируешь, а не оригинальный. Затем там создаешь привычно ветку и пушишь ее.
Заходишь в гитхаб-битбакет исходного репозитория, жмешь «Создать мердж-реквест», выбираешь свою ветку, она будет называться примерно vasya/adminka/blog/new-field, и ждешь, пока мердж-реквест примут.
Пока все ровно так, как ты привык, ничего нового. Мердж-реквест принимают и все хорошо.
Через месяц тебе нужно сделать еще одну задачу. Ты привычно подтягиваешь мастер и настораживаешься
За месяц нет новых коммитов в мастере? Да не верю. Идешь в репозиторий админки, смотришь, там до фига коммитов, чуть не каждый день в мастер пушат. В чем дело?
Присматриваешься, откуда ты пулишься и видишь, что это vasya/adminka. Это твой репозиторий, твой форк. Конечно, ты его месяц не трогал и он ничего не знает о новых коммитах в исходном проекте. Их нужно подтянуть и только тогда создавать новую ветку. Можно сделать это так
То есть вместо origin указываешь адрес нужного репозитория. И вот теперь-то подтянется мастер именно исходного проекта, а не твоего. А еще лучше сделать так, чтобы не набивать каждый раз длинный адрес
Теперь у тебя есть origin — твой репозиторий, твой форк, а есть upstream — оригинальный репозиторий. И ты можешь пулиться, указывая сразу upstream
Вот теперь твой мастер актуален, можешь создавать ветку и пушить в репозиторий. Пушить уже в origin, то есть свой, потому что в upstream, исходный, тебе пушить никто не даст. То есть еще раз, пулишь мастер так
а пушишь свою ветку так
По сути это все, что нужно знать о работе с форками. После этого идешь создавать мердж-реквест, твоя ветка уже видна в исходном репозитории. Если ты работал над веткой, а за это время в мастер накидали еще коммитов, то перед отправкой мердж-реквеста стоит отребейзиться от мастера
Тут можешь делать, как хочешь, твой форк, твои правила. Можешь пушить с форсом, как у меня в примере. Если не хочешь с форсом, то можешь создать отдельную ветку и положить коммит в нее. Как угодно. Главное, чтобы твои коммиты лежали поверх свежих коммитов из мастера. Тогда никто не будет возникать при рассмотрении мердж-реквеста, а ты будешь уверен, что у тебя самые свежие обновления.
Подробнее почитать про ребейз можно здесь — git merge и rebase.
И на этом все. Главное, что нужно сделать, это добавить upstream и четко понимать, в чем его отличие от origin.
С форками можно работать и в компании на полсотни разработчиков, но особенно это популярно в опенсорсе. Возьмите какой-нибудь проект, например, vuejs, у него больше 20 тысяч форков и 3 сотни контрибьюторов. Представьте, что бы творилось в репозитории, пусти всех этих энтузиастов пушить свои правки. А так они спокойно работают со своими форками и присылают пулл-реквесты, не засоряя проект.
Всем удачи. Любите гит, он совсем не страшный 🙂
Источник
GitHub не позволяет разветвить форк, если у вас есть форк?
Теперь я хочу получить ответвление №3, то есть https://github.com/hill-a/stable -baselines. Тем не менее, GitHub не позволяет этого, говоря: «Вы уже разобрали стабильные базовые уровни». У меня на самом деле нет форка стабильных базовых линий, а есть только его родитель. Так что сообщение неверно. В любом случае, это не имеет смысла для меня вообще. № 3 в настоящее время значительно разошлись и имеют много разных функций. Я хочу отправить запрос на получение ответа обоим. Однако, не имея обеих вилок, я не могу этого сделать.
2 ответа
Хотя @VonC предоставил тот факт, что невозможно получить два разных форка, я хочу добавить к этому ответу две вещи:
Во-первых, GitHub считает, что это неудачное дизайнерское решение, и нет никаких технических причин, чтобы этого не допустить. Каждый репо должен быть в состоянии указать на то, что он хочет, чтобы механизм PR работал. Для платформы, которая намеревается содействовать совместной разработке, это является ошеломляющим ограничением.
Во-вторых, я хочу предоставить способ, которым вы можете все еще делать это, но с дополнительной работой с вашей стороны. Допустим, у некоторых пользователей есть репо R и две их вилки R1 и R2. Вы хотите иметь возможность работать с R, R1 и R2 и отправлять им свои запросы на извлечение. Вот как вы можете сделать это:
- Клонируйте R локально, а затем создайте новое репозиторий github. Это будет означать, что ваш репо не будет отображаться как форк, и вы не сможете отправлять PR от него на R.
- Добавьте пульты для каждой вилки, используя git remote add r1_fork https://github.com/ /R1.git .
- Для каждого разветвления создайте свою собственную ветку, используя git checkout -b r1_fork .
- В каждой ветке извлеките изменения из этой ветки: git fetch r1_fork .
- После выборки выполните полный сброс в этой ветке для этого пульта: git reset —hard r1_fork/master .
Теперь вы можете работать в ветке для каждого отдельного пульта и вносить изменения. Тем не менее, вы пока не можете отправлять PR. Для отправки PR вам нужно будет форкать репо, затем объединить изменения из вашей ветки с веткой, отправить PR и удалить форк. Очевидно, это очень неидеально, но это то, что мы получили, пока GitHub не исправит их.
Если репозиторий № 3 разошелся, то для владельца # 3 было бы целесообразно создать отдельный репозиторий (не являющийся форком) с его содержимым, которое вы затем разветвите, чтобы включить PR.
Источник