Инструкция написана для сервиса github. Вам нужно войти в свой аккаунт или зарегистрироваться.
Все команды вводятся в терминале.
Шаг 1
Делаем fork (копию) нужного проекта. Переходим в свой аккаунт и заходим в только что созданный fork.
Шаг 2
Клонируем fork (копию) проекта из предыдущего шага на свой компьютер. Например, через SSH
git clone git@github.com:maxdzyubak/vite.git
Шаг 3
Настраиваем конфиг git локально (local). Нужно повторять для каждого проекта
git config --local user.name maxdzyubak
git config --local user.email maxdzyubak@gmail.com
Или глобально (global). Настроить один раз для всех проектов
git config --global user.name maxdzyubak
git config --global user.email maxdzyubak@gmail.com
Шаг 4
Делаем указатель на оригинальный репозиторий upstream откуда мы делали fork (копию). Он нужен для того, чтобы скачивать последние обновления кода из оригинального репозитория. (Проверка upstream: git remote -v)
git remote add upstream https://github.com/vitejs/vite.git
Шаг 5
Создаём новую ветку и сразу переходим в неё. Все изменения производим в ней. Это считается хорошей практикой
git checkout -b new_branch
Шаг 6
Проверить статус сделанных изменений можно командой
git status
Шаг 7
Добавляем изменения в отслеживаемые (staged). Git начинает следить за изменениями в этом файле/файлах
git add README.md
Шаг 8
Делаем коммит (commit) с изменениями. Если есть номер issue, то лучше всего в коммите написать так: [#123] fix bug. Если просто указать решётку без скобок, то при git rebase он её проигнорирует
git commit -m 'Update README.md'
Шаг 9
Проверить сделанный коммит
git log
Шаг 10
Пушим, сделанные изменения во внешний мир, так как пока они находятся только у нас локально на компьютере, c указанием созданной ветки
git push origin new_branch
Шаг 11
Создаём пулл реквест (pull request) нажатием на кнопку с названием Compare & pull request либо в оригинальном репозитории из которого делали fork
либо в нашем github аккаунте, в сделанном fork
Оффициальная документация
git-clone - Clone a repository into a new directory
Customizing Git - Git Configuration
git-remote - Manage set of tracked repositories
Git Branching - Basic Branching and Merging
git-status - Show the working tree status
git-add - Add file contents to the index
git-commit - Record changes to the repository
git-log - Show commit logs
git-push - Update remote refs along with associated objects
git-request-pull - Generates a summary of pending changes
Комментарии (22)
dlinyj
06.06.2023 11:52+2Нужно больше подобных статей, разбирающих детали совместной работы над проектами. Например, вот аналогичное описание давал в своей статье Правка чужого кода.
Спасибо вам за статью. Есть ли у вас пример того, как вы принимали участие в чужом проекте и удачно внесли изменения?
maxdzyubak Автор
06.06.2023 11:52+1Сергей, благодарю!
Я добавил свою конфигурацию использования кнопок клавиатуры вместо мыши (или трекпада) в программу karabiner на MacOS. Её можно найти в магазине karabiner по ссылке с на званием
Mouse full emulation with right command super fastтам будет справа указан мой никнейм создателя. Также можно найти по коммитам в репозитории на гитхаб.После этого маленького и скромного вклада своей настройки и принятия моего коммита, я вдохновился и решил написать статью)
YegorP
06.06.2023 11:52+5Шаг 1
Делаемfork(копию) нужного проекта. Переходим в свой аккаунт и заходим в только что созданныйfork.Не обязательно сразу форк делать. Можно спокойно работать в репозитории, склонированном с оригинала, и по готовности коммита уже создавать форк в ГХ да прописывать его как новый ремоут.
shark14
06.06.2023 11:52А какой смысл в таком дополнительном действии, если вы изначально уже точно знаете, что хотите создать пулл-реквест?
Aldrog
06.06.2023 11:52+3Если хочется сделать конкретное тривиальное изменение, то смысла нет. А если вы ковыряетесь в незнакомой кодовой базе, разбираетесь, экспериментируете с добавлением нужной функциональности, то зачастую удобнее просто скачать и начать разбираться, а форк создать уже когда начнёт что-то осмысленное вырисовываться.
valery1707
06.06.2023 11:52+13Создаём новую ветку и сразу переходим в неё.
git switch -c new_branchКоманда switch в актуальной версии
2.41.0является эксперементальной и её поведение может быть изменено в новых версиях - лучше её не использовать в публичных инструкциях.Такое же поведение (создание ветки с переходом в нёё) достигается использованием стабильной команды checkout с флагом
-b:git checkout -b new_branch
Vest
06.06.2023 11:52+2Осталось добавить, что для чужих проектов есть определенные стили в написании кода. Кому-то JIRA тикет надо создать, кто-то попросит форматирование, других надо будет умолять во всяких чатах-дискордах.
А так да, бери и коммить.
Sild
06.06.2023 11:52+20Это какой-то бред. Вы туториал по гиту по сути написали, еще и довольно коряво
Смотрите как можно: жамкаете кнопку fork, затем на форке:
git clone ... git commit -a -m ".." git pushЗатем Жамкаете кнопку "Create pull request".
Весь сок в 7-8 этапе:
Найти проект, который ваш нонейм-пул-реквест вообще будет рассматривать
Найти подходящий issue из открытых, или открыть свой если подходящего нет - а фича полезная
Разобраться в стиле, применяемом в данном проекте
Обсудить предполагаемое решение с владельцами кода, что поможет учесть различные неочевидные корнер-кейсы
Обсудить альтернативные решения, плюсы и минусы
Обновить документацию (для опенсорс-проектов это пипец как важно)
Убедить мейнтейнеров что ваш фикс достаточно важен что его нужно влить
Вот это - коммиты в опенсорс, а не
git commit -am
saboteur_kiev
06.06.2023 11:52+2Можно вообще не лазить в командную строку и править файлы прямо в вебUI гитхаба.
Главное что нужно делать при коммите в опенсорс - это почитать правила конкретного опенсорс-проекта, почитать их инструкции и code style.А в статье описано больше базовые команды гита.... Ну мне кажется что для коммита в опенсорс знать как работает базовый функционал гита это вообще маст хев.
nronnie
06.06.2023 11:52+1Шаги 1-4 можно сделать всего одной командой, поставив перед этим GitHub CLI (я думаю, что почти у всех, кто работает с GitHub он установлен:
winget install --id GitHub.cli --source winget --silent)gh repo имя/репы fork --clone --remoteC остальными шагами тоже самое :)
maxdzyubak Автор
06.06.2023 11:52Благодарю за комментарий. Я не использовал GitHub CLI и есть те, кто про него не знают. Закреплю ваш комментарий.
ivankudryavtsev
06.06.2023 11:52+1Мне кажется, что все самое интересное начинается после отправки PR.
kompilainenn2
06.06.2023 11:52+1А теперь представьте, что у проекта своя инфраструктура, не связанная с гитхаб.
И да, самое сложное при попытках коммитить в опенсорц, это разобраться в кодовой базе проекта, запилить патч, устранить все замечания от ревьюера, не психовать при этом. А знание гит это просто само собой разумеется для разработчика в наши дни
nronnie
Шаги 1-4 можно сделать всего одной командой, поставив перед этим GitHub CLI (я думаю, что почти у всех, кто работает с GitHub он установлен:
winget install --id GitHub.cli --source winget --silent)C остальными шагами тоже самое :)