06.06.2023 11:50
maxdzyubak 22 4200 Источник

Инструкция написана для сервиса github. Вам нужно войти в свой аккаунт или зарегистрироваться.

Все команды вводятся в терминале.

Шаг 1

Делаем fork (копию) нужного проекта. Переходим в свой аккаунт и заходим в только что созданный fork.

Делаем fork нужного проекта
Делаем fork нужного проекта
Наш сделанный fork в нашем github аккаунте
Наш сделанный fork в нашем github аккаунте

Шаг 2

Клонируем fork (копию) проекта из предыдущего шага на свой компьютер. Например, через SSH

Копируем адрес fork репозитория через ssh
Копируем адрес 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

Pull request в оригинальном репозитории
Pull request в оригинальном репозитории

либо в нашем github аккаунте, в сделанном fork 

Pull request в нашем аккаунте github, в сделанном fork
Pull request в нашем аккаунте 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)


  1. nronnie
    06.06.2023 11:52
    #0
    +1

    Шаги 1-4 можно сделать всего одной командой, поставив перед этим GitHub CLI (я думаю, что почти у всех, кто работает с GitHub он установлен: winget install --id GitHub.cli --source winget --silent)

    gh repo имя/репы fork --clone --remote

    C остальными шагами тоже самое :)


  1. dlinyj
    06.06.2023 11:52
    #25621494
    +2

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


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


    1. maxdzyubak Автор
      06.06.2023 11:52
      #25622148
      +1

      Сергей, благодарю!

      Я добавил свою конфигурацию использования кнопок клавиатуры вместо мыши (или трекпада) в программу karabiner на MacOS. Её можно найти в магазине karabiner по ссылке с на званием Mouse full emulation with right command super fast там будет справа указан мой никнейм создателя. Также можно найти по коммитам в репозитории на гитхаб.

      После этого маленького и скромного вклада своей настройки и принятия моего коммита, я вдохновился и решил написать статью)


      1. dlinyj
        06.06.2023 11:52
        #25624576
        +1

        Спасибо, мотивируют такие истории!


        1. maxdzyubak Автор
          06.06.2023 11:52
          #25624796
          +1

          Благодарю, Сергей! Я замотивирован ещё больше)))


  1. YegorP
    06.06.2023 11:52
    #25621530
    +5

    Шаг 1
    Делаем fork (копию) нужного проекта. Переходим в свой аккаунт и заходим в только что созданный fork.

    Не обязательно сразу форк делать. Можно спокойно работать в репозитории, склонированном с оригинала, и по готовности коммита уже создавать форк в ГХ да прописывать его как новый ремоут.


    1. shark14
      06.06.2023 11:52
      #25621894

      А какой смысл в таком дополнительном действии, если вы изначально уже точно знаете, что хотите создать пулл-реквест?


      1. Aldrog
        06.06.2023 11:52
        #25621928
        +3

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


        1. maxdzyubak Автор
          06.06.2023 11:52
          #25622158

          Принял на заметку)


    1. maxdzyubak Автор
      06.06.2023 11:52
      #25622152
      +1

      Егор, благодарю! Буду знать!


  1. valery1707
    06.06.2023 11:52
    #25621550
    +13

    Создаём новую ветку и сразу переходим в неё.

    git switch -c new_branch

    Команда switch в актуальной версии 2.41.0 является эксперементальной и её поведение может быть изменено в новых версиях - лучше её не использовать в публичных инструкциях.

    Такое же поведение (создание ветки с переходом в нёё) достигается использованием стабильной команды checkout с флагом -b:

    git checkout -b new_branch


    1. maxdzyubak Автор
      06.06.2023 11:52
      #25622192
      +1

      Валерий, благодарю! Отредактировал


  1. Vest
    06.06.2023 11:52
    #25621750
    +2

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

    А так да, бери и коммить.


  1. Sild
    06.06.2023 11:52
    #25621896
    +20

    Это какой-то бред. Вы туториал по гиту по сути написали, еще и довольно коряво

    Смотрите как можно: жамкаете кнопку fork, затем на форке:

    git clone ...
git commit -a -m ".."
git push

    Затем Жамкаете кнопку "Create pull request".

    Весь сок в 7-8 этапе:

    • Найти проект, который ваш нонейм-пул-реквест вообще будет рассматривать

    • Найти подходящий issue из открытых, или открыть свой если подходящего нет - а фича полезная

    • Разобраться в стиле, применяемом в данном проекте

    • Обсудить предполагаемое решение с владельцами кода, что поможет учесть различные неочевидные корнер-кейсы

    • Обсудить альтернативные решения, плюсы и минусы

    • Обновить документацию (для опенсорс-проектов это пипец как важно)

    • Убедить мейнтейнеров что ваш фикс достаточно важен что его нужно влить

    Вот это - коммиты в опенсорс, а не git commit -am


    1. maxdzyubak Автор
      06.06.2023 11:52
      #25622244
      +2

      Благодарю за крутое дополнение! Закрепил ваш коммент.


  1. saboteur_kiev
    06.06.2023 11:52
    #25621922
    +2

    Можно вообще не лазить в командную строку и править файлы прямо в вебUI гитхаба.

    Главное что нужно делать при коммите в опенсорс - это почитать правила конкретного опенсорс-проекта, почитать их инструкции и code style.

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


    1. maxdzyubak Автор
      06.06.2023 11:52
      #25625194

      Сергей, благодарю. Взял на заметку про UI гитхаба)


  1. nronnie
    06.06.2023 11:52
    #25622276
    +1

    Шаги 1-4 можно сделать всего одной командой, поставив перед этим GitHub CLI (я думаю, что почти у всех, кто работает с GitHub он установлен: winget install --id GitHub.cli --source winget --silent)

    gh repo имя/репы fork --clone --remote

    C остальными шагами тоже самое :)


    1. maxdzyubak Автор
      06.06.2023 11:52
      #25622492

      Благодарю за комментарий. Я не использовал GitHub CLI и есть те, кто про него не знают. Закреплю ваш комментарий.


  1. ivankudryavtsev
    06.06.2023 11:52
    #25623048
    +1

    Мне кажется, что все самое интересное начинается после отправки PR.


    1. maxdzyubak Автор
      06.06.2023 11:52
      #25625204

      Но это уже совсем другая история)))


  1. kompilainenn2
    06.06.2023 11:52
    #25623170
    +1

    А теперь представьте, что у проекта своя инфраструктура, не связанная с гитхаб.

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


    1. maxdzyubak Автор
      06.06.2023 11:52
      #25625212

      Согласен с вами