что такое fork в git

Git fork. Зачем нужны форки и как с ними работать

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

Я не сторонник подхода «чо тут не понимать, тупой штоле» и попробую рассказать человеческими словами, что вообще такое форки, зачем они нужны и как с ними работать. А вы оцените, как получилось. Синьор git девелоперам статья покажется банальщиной, но тем, кто еще не успел обрести такой титул, будет полезно.

Ты работаешь в компании Company в какой-то команде и со своими ребятами пишешь код, например, блога вашего сайта. Рядом сидят ребята из другой команды, которые занимаются админкой. У каждой команды отдельный репозиторий, вы работаете и друг другу не мешаете.

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

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

Рано или поздно ребятам из админки это надоедает, потому что у них хватает и своей работы. Они предлагают вам дать права на репозиторий и пробовать такие небольшие задачи делать самим. Говорят, мол, с такой фигней типа добавления поля в респонс вы и сами справитесь. Если что, зовите, поможем. Прав на пуш в мастер, конечно, никто не даст, но свои ветки создавайте и присылайте мердж-реквесты. Мы смотрим, если все хорошо, то мерджим в мастер и выкладываем в прод. Все довольны. И нам работы меньше, и вам не ждать, пока у нас руки дойдут до вашей задачи.

Вы с командой соглашаетесь. Ты клонируешь их репозиторий и пилишь фичи. Примерно так

Дальше идешь в битбакеты-гитхабы, в репозиторий админки, делаешь мердж-реквест и ждешь, когда его примут. Обычная схема. Мердж-реквест примерно везде делается одинаково: ищешь кнопку «Создать мердж-реквест» или пулл-реквест, выбираешь свою ветку, затем выбираешь, куда сливать (обычно уже по умолчанию будет мастер) и жмешь «Отправить».

Проходит пара месяцев. Ты случайно замечаешь в репозитории админки ветку petya/update-email. Спрашиваешь ребят из админки, а что за Петя вам коммитит? Те говорят, а, это чувак из отдела емейлов, мы им тоже доступ дали, как и вам. Они тоже приходили к нам по 3 раза в месяц, мы задолбались и теперь с ними работаем по вашей схеме. Ничего, все довольны.

Проходит год. Команд, которые работают по такой схеме, уже десяток. В репозитории появляются ветки

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

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

Это дело хорошее, но бесполезное. В компании полсотни разрабов, у каждого своя команда и свои правила работы с репозиторием. Люди приходят и уходят, эти правила уже никто не помнит, да и всем пофигу, главное фичу сделать, чего там заморачиваться с ветками и коммитами. Пусть у команды админки об этом голова болит. Главное, у нас все хорошо, в своем командном проекте, потому что мы никого к себе не пускаем, ахаха. Поэтому и ветки красиво называются, и коммиты адекватно подписаны. Нас тут 5 человек работают, уж между собой-то договоримся.

А между тем в репозитории админки образуется все больший трэш. То злодеи опять пушат ветки с названиями не по ГОСТу, и тимлида бесят. То сам тимлид с похмелья выдал новому чуваку доступы на пуш в мастер, а тот на радостях запушил миграцию, которая пол-сайта уронила. То по ошибке смерджили petya/hotfix вместо vasya/hotfix. В общем весело всем, кроме ребят из админки.

И вот однажды что-то изменилось. Тебе понадобилось запилить новую фичу и ты привычно набиваешь

Сначала идешь в гитхаб-битбакет и ищешь там в нужном репозитории кнопку Fork. Обычно она недалеко от кнопки clone. Жмешь на fork и для тебя создается проект. Если исходный был company/adminka.git, то твой будет примерно vasya/adminka.git. Ну или примерно так. Дальше клонируешь его как обычно

Естественно, свой форк клонируешь, а не оригинальный. Затем там создаешь привычно ветку и пушишь ее.

Заходишь в гитхаб-битбакет исходного репозитория, жмешь «Создать мердж-реквест», выбираешь свою ветку, она будет называться примерно vasya/adminka/blog/new-field, и ждешь, пока мердж-реквест примут.

Пока все ровно так, как ты привык, ничего нового. Мердж-реквест принимают и все хорошо.

Через месяц тебе нужно сделать еще одну задачу. Ты привычно подтягиваешь мастер и настораживаешься

За месяц нет новых коммитов в мастере? Да не верю. Идешь в репозиторий админки, смотришь, там до фига коммитов, чуть не каждый день в мастер пушат. В чем дело?

Присматриваешься, откуда ты пулишься и видишь, что это vasya/adminka. Это твой репозиторий, твой форк. Конечно, ты его месяц не трогал и он ничего не знает о новых коммитах в исходном проекте. Их нужно подтянуть и только тогда создавать новую ветку. Можно сделать это так

То есть вместо origin указываешь адрес нужного репозитория. И вот теперь-то подтянется мастер именно исходного проекта, а не твоего. А еще лучше сделать так, чтобы не набивать каждый раз длинный адрес

Вот теперь твой мастер актуален, можешь создавать ветку и пушить в репозиторий. Пушить уже в origin, то есть свой, потому что в upstream, исходный, тебе пушить никто не даст. То есть еще раз, пулишь мастер так

а пушишь свою ветку так

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

Тут можешь делать, как хочешь, твой форк, твои правила. Можешь пушить с форсом, как у меня в примере. Если не хочешь с форсом, то можешь создать отдельную ветку и положить коммит в нее. Как угодно. Главное, чтобы твои коммиты лежали поверх свежих коммитов из мастера. Тогда никто не будет возникать при рассмотрении мердж-реквеста, а ты будешь уверен, что у тебя самые свежие обновления.

И на этом все. Главное, что нужно сделать, это добавить upstream и четко понимать, в чем его отличие от origin.

С форками можно работать и в компании на полсотни разработчиков, но особенно это популярно в опенсорсе. Возьмите какой-нибудь проект, например, vuejs, у него больше 20 тысяч форков и 3 сотни контрибьюторов. Представьте, что бы творилось в репозитории, пусти всех этих энтузиастов пушить свои правки. А так они спокойно работают со своими форками и присылают пулл-реквесты, не засоряя проект.

Всем удачи. Любите гит, он совсем не страшный 🙂

Источник

Как сделать первый пул-реквест на GitHub

Перевод статьи «How to make your first pull request on GitHub».

Что такое форк?

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

Когда мы делаем форк репозитория, мы получаем экземпляр всего репозитория, со всей его историей. После форка мы можем делать с ним все, что угодно: оригинальная версия при этом не будет задета.

Что такое пул-реквест?

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

Например, пользователь Павел делает форк репозитория ThanoshanMV (автора статьи, — прим. перев.) и вносит изменения в свой экземпляр. После этого Павел отсылает пул-реквест ThanoshanMV, который может либо принять его, либо отклонить. По сути это что-то вроде письма «Не будете ли вы так любезны, уважаемый ThanoshanMV, внести мои изменения в свой оригинальный репозиторий?»

Как можно стать контрибьютором проекта?

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

Давайте создадим наш первый пул-реквест!

1. Форк репозитория

Чтобы сделать форк репозитория, нужно нажать кнопку «Fork» в верху страницы. Таким образом вы создадите экземпляр всего этого репозитория в своем аккаунте.

2. Клонирование репозитория

Когда репозиторий уже есть в вашем аккаунте, вы можете клонировать его на свою машину и в дальнейшем работать с ним локально.

Чтобы клонировать репозиторий, нажмите кнопку «clone» и скопируйте ссылку.

Откройте терминал и запустите следующую команду. С ее помощью репозиторий будет клонирован на вашу машину.

Теперь у вас есть копия ветки master основного онлайн-репозитория проекта.

Переходим в клонированную директорию:

3. Создание ветки

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

Имя ветки должно быть коротким и отражать те изменения, которые вы вносите.

Создадим ветку при помощи команды git checkout:

4. Внесение изменений и коммит

Внесите необходимы изменения в проект и сохраните их. Затем запустите команду git status: вы увидите внесенные изменения.

Добавьте эти изменения в только что созданную ветку при помощи команды git add:

Теперь вы можете сделать коммит этих изменений при помощи команды git commit:

5. Отправка изменений на GitHub

Чтобы отправить изменения на GitHub (сделать push), нужно определить имя удаленного репозитория.

Имя данного удаленного репозитория — «origin».

После определения имени можно безопасно отправить изменения на GitHub.

6. Создание пул-реквеста

Перейдите в свой репозиторий на GitHub. Там есть кнопка «Compare & pull request» — кликните ее.

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

Поздравляю! Вы создали свой первый пул-реквест. Если его примут, вы получите уведомление по электронной почте.

7. Синхронизация вашего форка с основной веткой

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

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

Проделайте следующие действия, чтобы обновить свой репозиторий и внести соответствующие изменения в свою ветку master:

1. Для начала, проверьте, в какой ветке вы находитесь.

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

2. Переключитесь в ветку master.

3. Добавьте оригинальный репозиторий в качестве upstream-репозитория.

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

Здесь [HTTPS] это url, который нужно скопировать из основного репозитория.

4. Fetch репозитория

Заберите (fetch) все изменения из оригинального репозитория. Коммиты, сделанные в оригинальном репозитории, будут сохранены в локальной ветке под названием upstream/master.

5. Слейте изменения

Слейте (merge) изменения из upstream/master с вашей локальной веткой master. Таким образом главная ветка вашего форка репозитория синхронизируется с upstream-репозиторием без потери ваших локальных изменений.

6. Отправьте изменения на GitHub

На этом этапе ваша локальная ветка синхронизирована с веткой master оригинального репозитория. Если вы хотите обновить свой GitHub-репозиторий, нужно отправить в него изменения.

Примечание. После синхронизации ветки master вашего форка вы можете при желании удалить remote. Но в будущем вам еще придется обновлять/синхронизировать ваш репозиторий, поэтому лучше его сохранить.

8. Удаление ненужной ветки

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

Вы можете удалить и версию этой ветки на GitHub.

Итоги

GitHub это мощный инструмент для контроля истории версий. Каждый может стать контрибьютором проекта с открытым исходным кодом. Делается это путем отправки пул-реквестов.

Чтобы стать контрибьютором, не обязательно писать код: есть и другие способы принять участие в проекте.

Наконец, я хотел бы также сказать, что не стоит переживать, если ваши пул-реквесты отклонят. Мейнтейнеры тратят много времени на улучшение своих проектов и они, безусловно, лучше знают эти проекты, чем вы. Поэтому не стоит переживать, если они решат не вливать в свой проект ваши изменения.

Источник

sergey vasin

The IT blog

GitHub: fork, clone и другие

Существующие репозитории чаще всего используются в двух случаях: для начала разработки своего проекта, причем не с нуля, а с использованием чьего-либо кода (Open Source!) или же для того, чтобы предложить внесение изменений в чей-либо уже существующий код. При этом во втором случае предполагается, что все изменения вы вносите в свой репозиторий, а к принятию их предлагаете уже в готовом виде.

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

Давайте в качестве примера предположим, что нас одолело нестерпимое желание помочь в локализации справочной информации для PowerShell и мы решили создать копию репозитория PowerShell/powerShell-Docs.ru-ru.

При этом мы также предполагаем, что у нас уже создан профиль на сайте github.com, и установлен и настроен Git Bash.

Для разветвления репозитория нам нужно найти его на сайте github.com, в нашем случае это будет https://github.com/PowerShell/powerShell-Docs.ru-ru и в правом верхнем углу нажать кнопку Fork. Через некоторое время в нашем профиле мы увидим копию нужного нам репозитория.

Clone

Так как работать с файлами репозитория мы, скорее всего, будем локально, с использованием каких-либо инструментов, например, Visual Studio Code, то стоит создать копию файлов уже, можно сказать, нашего репозитория на своем компьютере.

Этот процесс называется клонированием.

Для начала, нам нужен адрес, по которому расположен наш репозиторий. Для этого мы заходим в свой профиль на сайте github.com, переходим в нужный нам репозиторий и нажимаем кнопку Clone or download. В результате откроется окно со ссылкой на этот репозиторий, которую нам потребуется скопировать.

Далее мы открываем Git Bash, переходим в папку, где располагаются наши репозитории (хотя это может быть и новый, отведенный специально для целей хранения конкретного репозитория каталог) и вводим команду:

Syncing repos

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

Для начала нам нужно перейти на страницу оригинального репозитория, в нашем случае это https://github.com/PowerShell/powerShell-Docs.ru-ru, точно так же, как и в предыдущем случае, нажать кнопку Clone or download и скопировать предложенную ссылку в буфер обмена.

Далее нам потребуется вернуться в Git Bash и перейти в директорию репозитория, клонированного нами при помощи предыдущей команды.

Если мы введем команду:

то мы увидим что-то вроде:

Давайте добавим информацию об оригинальном репозитории при помощи команды:

Теперь, введя еще раз команду:

мы заметим, что вывод стал включать еще две строки:

Таким образом, мы создали запись об оригинальном репозитории, с которым мы будем синхронизироваться.

Теперь давайте обсудим несколько терминов.

clone — это расположенный на вашем компьютере репозиторий. В него вы будете вносить изменения и синхронизировать с вашим репозиторием (origin), расположенным на сайте github.com

remote — это репозитории, которые находятся на сайте github.com. То есть, те, что не являются локальными. К ним относится и origin, и upstream.

origin — это репозиторий, расположенный в вашем профиле и находящийся на сайте github.com. Это тот репозиторий, с которого вы делали клон для использования на локальном компьютере.

upstream — это оригинальный репозиторий, на основе которого посредством операции fork был создан репозиторий, расположенный в вашем профиле сайта github.com. Именно его изменения вы будете синхронизировать в расположенный на вашем локальном компьютере репозиторий.

Что тут интересно, так это то, что при синхронизации изменений из upstream, будет затронут только локальный, расположенный на вашем компьютере, репозиторий. Для того, чтобы синхронизированные изменения были также отражены в вашем репозитории на сайте github.com (origin), вам потребуется использовать команду git push. Но об этом чуть позже.

Итак, мы добавили информацию об upstream, теперь перейдем непостредственно к процессу синхронизации.

Для того, чтобы получить информацию о произведенных в upstream изменениях, введем следующую команду:

Далее нам нужно выбрать ветвь (branch) локального репозитория, в которую мы собираемся синхронизировать изменения. Обычно она соответствует ветви оригинального (upstream) репозитория. В случае репозитория powerShell-Docs.ru-ru на момент написания основной ветвью является live. Сделаем мы это следующей командой:

Теперь произведем синхронизацию изменений из ветви live оригинального репозитория:

Вместо использования команд fetch и merge по отдельности, мы можем воспользоваться командой pull, что приведет к тому же самому результату.

Branch

Для того, чтобы не вносить изменения непосредственно в основную ветвь (branch), вы можете создать отдельную ветвь специально для целей редактирования.

Для перехода к использованию созданной вами ветви введите следующую команду:

Для просмотра существующих локальных ветвей используется команда:

Для переименования ветви old_name в new_name команда:

Для удаления ветви branch_name:

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

Используется для этого команда push. В качестве аргументов указываются удаленный репозиторий, куда будут передаваться изменения (например, origin) и имя ветви.

В нашем случае команда может выглядеть так:

Что касается имени ветви в вашем репозитории на сайте guthub.com, то оно не обязательно должно соответствовать имени локальной ветви. Например, чтобы передать содержимое ветви localbranch в ветвь remotebranch в вашем репозитории на сайте github.com, используйте следующую команду:

Чтобы удалить ветвь репозитория remotebranch на github.com, используйте команду:

Pull request

Для того, чтобы предложить владельцам оригинального репозитория внести ваши изменения и дополнения в свой проект, вам потребуется создать Pull request.

Для этого перейдите на страницу вашего репозитория на сайте github.com, при помощи кнопки Branch: выберите ветвь, содержимое которой вы хотели бы внести в оригинальный репозиторий и нажмите кнопку New pull request.

На открывшейся странице выберите репозиторий и ветвь куда бы вы хотели добавить ваш код (кнопки base fork: и base:), а также, при необходимости, измените репозиторий и ветвь, содержимое которых вы бы хотели предложить для добавления (кнопки head fork: и compare:), введите заголовок и описание вашего запроса и нажмите кнопку Create pull request.

Источник

Fork a repo

In this article

A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project.

Most commonly, forks are used to either propose changes to someone else’s project or to use someone else’s project as a starting point for your own idea. You can fork a repository to create a copy of the repository and make changes without affecting the upstream repository. For more information, see «Working with forks.»

Propose changes to someone else’s project

For example, you can use forks to propose changes related to fixing a bug. Rather than logging an issue for a bug you’ve found, you can:

Use someone else’s project as a starting point for your own idea.

Open source software is based on the idea that by sharing code, we can make better, more reliable software. For more information, see the «About the Open Source Initiative» on the Open Source Initiative.

For more information about applying open source principles to your organization’s development work on GitHub.com, see GitHub’s white paper «An introduction to innersource.»

When creating your public repository from a fork of someone’s project, make sure to include a license file that determines how you want your project to be shared with others. For more information, see «Choose an open source license» at choosealicense.com.

For more information on open source, specifically how to create and grow an open source project, we’ve created Open Source Guides that will help you foster a healthy open source community by recommending best practices for creating and maintaining repositories for your open source project. You can also take a free GitHub Learning Lab course on maintaining open source communities.

If you haven’t yet, you should first set up Git. Don’t forget to set up authentication to GitHub.com from Git as well.

Forking a repository

You might fork a project to propose changes to the upstream, or original, repository. In this case, it’s good practice to regularly sync your fork with the upstream repository. To do this, you’ll need to use Git on the command line. You can practice setting the upstream repository using the same octocat/Spoon-Knife repository you just forked.

To learn more about GitHub CLI, see «About GitHub CLI.»

To create a fork of a repository, use the gh repo fork subcommand.

Cloning your forked repository

Right now, you have a fork of the Spoon-Knife repository, but you don’t have the files in that repository locally on your computer.

On GitHub.com, navigate to your fork of the Spoon-Knife repository.

Above the list of files, click

To clone the repository using HTTPS, under «Clone with HTTPS», click

. To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click Use SSH, then click

. To clone a repository using GitHub CLI, click Use GitHub CLI, then click

.

Change the current working directory to the location where you want the cloned directory.

Press Enter. Your local clone will be created.

To learn more about GitHub CLI, see «About GitHub CLI.»

In the File menu, click Clone Repository.

Click the tab that corresponds to the location of the repository you want to clone. You can also click URL to manually enter the repository location.

Choose the repository you want to clone from the list.

Click Choose. and navigate to a local path where you want to clone the repository.

Click Clone.

Configuring Git to sync your fork with the original repository

When you fork a project in order to propose changes to the original repository, you can configure Git to pull changes from the original, or upstream, repository into the local clone of your fork.

On GitHub.com, navigate to the octocat/Spoon-Knife repository.

Above the list of files, click

To clone the repository using HTTPS, under «Clone with HTTPS», click

. To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click Use SSH, then click

. To clone a repository using GitHub CLI, click Use GitHub CLI, then click

.

Change directories to the location of the fork you cloned.

Now, you can keep your fork synced with the upstream repository with a few Git commands. For more information, see «Syncing a fork.»

To learn more about GitHub CLI, see «About GitHub CLI.»

You can make any changes to a fork, including:

Find another repository to fork

Fork a repository to start contributing to a project. You can fork a repository to your user account or any organization where you have repository creation permissions. For more information, see «Roles in an organization.»

If you have access to a private repository and the owner permits forking, you can fork the repository to your user account or any organization on GitHub Team where you have repository creation permissions. You cannot fork a private repository to an organization using GitHub Free. For more information, see «GitHub’s products.»

You can browse Explore to find projects and start contributing to open source repositories. For more information, see «Finding ways to contribute to open source on GitHub.»

You have now forked a repository, practiced cloning your fork, and configured an upstream repository. For more information about cloning the fork and syncing the changes in a forked repository from your computer see «Set up Git.»

You can also create a new repository where you can put all your projects and share the code on GitHub. For more information see, «Create a repository.»

Each repository in GitHub is owned by a person or an organization. You can interact with the people, repositories, and organizations by connecting and following them on GitHub. For more information see «Be social.»

GitHub has a great support community where you can ask for help and talk to people from around the world. Join the conversation on Github Support Community.

Help us make these docs great!

All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.

Источник