Comments 23
Нужно больше подобных статей, разбирающих детали совместной работы над проектами. Например, вот аналогичное описание давал в своей статье Правка чужого кода.
Спасибо вам за статью. Есть ли у вас пример того, как вы принимали участие в чужом проекте и удачно внесли изменения?
Это какой-то бред. Вы туториал по гиту по сути написали, еще и довольно коряво
Смотрите как можно: жамкаете кнопку fork, затем на форке:
git clone ...
git commit -a -m ".."
git push
Затем Жамкаете кнопку "Create pull request".
Весь сок в 7-8 этапе:
Найти проект, который ваш нонейм-пул-реквест вообще будет рассматривать
Найти подходящий issue из открытых, или открыть свой если подходящего нет - а фича полезная
Разобраться в стиле, применяемом в данном проекте
Обсудить предполагаемое решение с владельцами кода, что поможет учесть различные неочевидные корнер-кейсы
Обсудить альтернативные решения, плюсы и минусы
Обновить документацию (для опенсорс-проектов это пипец как важно)
Убедить мейнтейнеров что ваш фикс достаточно важен что его нужно влить
Вот это - коммиты в опенсорс, а не git commit -am
Шаги 1-4 можно сделать всего одной командой, поставив перед этим GitHub CLI (я думаю, что почти у всех, кто работает с GitHub он установлен: winget install --id GitHub.cli --source winget --silent)
gh repo имя/репы fork --clone --remote
C остальными шагами тоже самое :)
Нужно больше подобных статей, разбирающих детали совместной работы над проектами. Например, вот аналогичное описание давал в своей статье Правка чужого кода.
Спасибо вам за статью. Есть ли у вас пример того, как вы принимали участие в чужом проекте и удачно внесли изменения?
Сергей, благодарю!
Я добавил свою конфигурацию использования кнопок клавиатуры вместо мыши (или трекпада) в программу karabiner на MacOS. Её можно найти в магазине karabiner по ссылке с на званием Mouse full emulation with right command super fast там будет справа указан мой никнейм создателя. Также можно найти по коммитам в репозитории на гитхаб.
После этого маленького и скромного вклада своей настройки и принятия моего коммита, я вдохновился и решил написать статью)
Шаг 1
Делаемfork(копию) нужного проекта. Переходим в свой аккаунт и заходим в только что созданныйfork.
Не обязательно сразу форк делать. Можно спокойно работать в репозитории, склонированном с оригинала, и по готовности коммита уже создавать форк в ГХ да прописывать его как новый ремоут.
А какой смысл в таком дополнительном действии, если вы изначально уже точно знаете, что хотите создать пулл-реквест?
Если хочется сделать конкретное тривиальное изменение, то смысла нет. А если вы ковыряетесь в незнакомой кодовой базе, разбираетесь, экспериментируете с добавлением нужной функциональности, то зачастую удобнее просто скачать и начать разбираться, а форк создать уже когда начнёт что-то осмысленное вырисовываться.
Егор, благодарю! Буду знать!
Создаём новую ветку и сразу переходим в неё.
git switch -c new_branch
Команда switch в актуальной версии 2.41.0 является эксперементальной и её поведение может быть изменено в новых версиях - лучше её не использовать в публичных инструкциях.
Такое же поведение (создание ветки с переходом в нёё) достигается использованием стабильной команды checkout с флагом -b:
git checkout -b new_branch
Осталось добавить, что для чужих проектов есть определенные стили в написании кода. Кому-то JIRA тикет надо создать, кто-то попросит форматирование, других надо будет умолять во всяких чатах-дискордах.
А так да, бери и коммить.
Это какой-то бред. Вы туториал по гиту по сути написали, еще и довольно коряво
Смотрите как можно: жамкаете кнопку fork, затем на форке:
git clone ...
git commit -a -m ".."
git push
Затем Жамкаете кнопку "Create pull request".
Весь сок в 7-8 этапе:
Найти проект, который ваш нонейм-пул-реквест вообще будет рассматривать
Найти подходящий issue из открытых, или открыть свой если подходящего нет - а фича полезная
Разобраться в стиле, применяемом в данном проекте
Обсудить предполагаемое решение с владельцами кода, что поможет учесть различные неочевидные корнер-кейсы
Обсудить альтернативные решения, плюсы и минусы
Обновить документацию (для опенсорс-проектов это пипец как важно)
Убедить мейнтейнеров что ваш фикс достаточно важен что его нужно влить
Вот это - коммиты в опенсорс, а не git commit -am
Можно вообще не лазить в командную строку и править файлы прямо в вебUI гитхаба.
Главное что нужно делать при коммите в опенсорс - это почитать правила конкретного опенсорс-проекта, почитать их инструкции и code style.
А в статье описано больше базовые команды гита.... Ну мне кажется что для коммита в опенсорс знать как работает базовый функционал гита это вообще маст хев.
Шаги 1-4 можно сделать всего одной командой, поставив перед этим GitHub CLI (я думаю, что почти у всех, кто работает с GitHub он установлен: winget install --id GitHub.cli --source winget --silent)
gh repo имя/репы fork --clone --remote
C остальными шагами тоже самое :)
Мне кажется, что все самое интересное начинается после отправки PR.
А теперь представьте, что у проекта своя инфраструктура, не связанная с гитхаб.
И да, самое сложное при попытках коммитить в опенсорц, это разобраться в кодовой базе проекта, запилить патч, устранить все замечания от ревьюера, не психовать при этом. А знание гит это просто само собой разумеется для разработчика в наши дни
Как коммитить в open source. Пошаговый гайд