Как перебазировать и обновить запрос на слияние

Введение

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

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

Предпосылки

Это руководство проведет вас через шаги, которые вы предпримете после создания запроса на вытягивание, поэтому у вас уже должен быть установлен Git, и вы либо сделали, либо думаете о создании запроса на вытягивание.

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

Чтобы узнать больше о том, как участвовать в проектах с открытым исходным кодом, вы можете прочитать How To Create a Pull Request на GitHub».

Перебазирование кода и очистка комментариев

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

Output
CONFLICT (content): Merge conflict in your-file.py
Automatic merge failed; fix conflicts and then commit the result.

Или вот так в вашем запросе на включение через веб-сайт GitHub:

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

Rebase позволяет нам перемещать ветки, изменяя фиксацию, на которой они основаны. Таким образом, мы можем перебазировать наш код, чтобы он основывался на последних коммитах основной ветки. Перебазирование следует выполнять с осторожностью, и вы должны убедиться, что работаете с правильными коммитами и в правильной ветке на протяжении всего процесса. Мы также рассмотрим использование команды git reflog ниже на случай, если вы допустите ошибку.

Как и в учебнике по запросу на включение, мы перейдем в каталог кода:

cd repository

Затем вы хотите убедиться, что находитесь в правильной ветке, перейдя к ней с помощью команды git checkout:

git checkout new-branch

Затем запустите git fetch для получения самой последней исходной версии кода:

git fetch origin

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

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

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

git log

Это даст вам вывод, похожий на этот:

Output
commit 46f196203a16b448bf86e0473246eda1d46d1273
Author: username-2 <email-2>
Date:   Mon Dec 14 07:32:45 2015 -0400

    Commit details

commit 66e506853b0366c87f4834bb6b39d941cd034fe3
Author: username1 <email-1>
Date:   Fri Nov 27 20:24:45 2015 -0500

    Commit details

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

git log --author=your-username

Указав этот параметр, вы сможете подсчитать сделанные вами коммиты. Если вы работаете с несколькими ветвями, вы можете добавить --branches[=<branch>] в конец вашей команды, чтобы ограничиться ветвями.

Теперь, если вы знаете количество сделанных вами коммитов в ветке, которую вы хотите перебазировать, вы можете запустить команду git rebase следующим образом:

git rebase -i HEAD~x

Здесь -i указывает на интерактивность перебазирования, а HEAD указывает на последнюю фиксацию из основной ветки. x будет количеством коммитов, которые вы сделали в своей ветке с момента ее первоначального извлечения.

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

git merge-base new-branch main

Эта команда вернет длинную строку, известную как хеш фиксации, которая выглядит примерно так:

Output
66e506853b0366c87f4834bb6b39d341cd094fe9

Мы будем использовать этот хэш коммита для передачи команде git rebase:

git rebase -i 66e506853b0366c87f4834bb6b39d341cd094fe9

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

Сквош совершает

Когда мы сжимаем сообщения коммитов, мы сжимаем или объединяем несколько меньших коммитов в один больший.

Перед каждым коммитом вы увидите слово «выбрать», поэтому ваш файл будет выглядеть примерно так, если у вас есть два коммита:

pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

Теперь для каждой строки файла, кроме первой строки, вы должны заменить слово «выбрать» на слово «сквош», чтобы объединить коммиты:

pick a1f29a6 Adding a new feature
squash 79c0e80 Here is another new feature

На этом этапе вы можете сохранить и закрыть файл, который откроет новый файл, объединяющий все сообщения коммитов всех коммитов. Вы можете перефразировать сообщение фиксации по своему усмотрению, а затем сохранить и закрыть файл.

Вы получите отзыв, как только закроете файл:

Output
Successfully rebased and updated refs/heads/new-branch.

Теперь вы объединили все коммиты в один, объединив их вместе.

Переформулировать коммиты

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

После того, как вы выполните интерактивную перебазировку, как описано выше, с помощью команды git rebase -i, у вас откроется файл, который выглядит следующим образом:

pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

Теперь для каждого коммита, который вы хотите перефразировать, замените слово «выбрать» на «перефразировать»:

pick a1f29a6 Adding a new feature
reword 79c0e80 Adding a second new feature

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

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

Завершите перебазирование

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

git rebase origin/main

В этот момент Git начнет воспроизводить ваши коммиты в последней версии main. Если во время этого возникают конфликты, Git сделает паузу, чтобы предложить вам разрешить конфликты, прежде чем продолжить. Если решать нечего, в выводе будет указано следующее:

Output
Current branch new-branch is up to date.

Как только вы исправите конфликты, вы запустите:

git rebase --continue 

Эта команда укажет Git, что теперь он может продолжить воспроизведение ваших коммитов.

Если вы ранее объединяли коммиты с помощью команды squash, вам нужно будет разрешать конфликты только один раз.

Обновите запрос на извлечение с помощью Force-Push

После выполнения перебазирования история вашей ветки изменится, и вы больше не сможете использовать команду git push, поскольку прямой путь был изменен.

Вместо этого нам придется использовать флаг --force или -f, чтобы принудительно отправить изменения, сообщая Git, что вы полностью осведомлены о том, что вы отправляете.

Давайте сначала убедимся, что наш push.default является simple, который используется по умолчанию в Git 2.0+, настроив его:

git config --global push.default simple

На этом этапе мы должны убедиться, что находимся в правильной ветке, проверив ветку, над которой мы работаем:

git checkout new-branch

Output
Already on 'new-branch'
. . .

Теперь мы можем выполнить принудительное нажатие:

git push -f

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

Восстановление потерянных коммитов

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

Мы будем использовать команду git reflog, чтобы найти недостающие коммиты, а затем создать новую ветку из этого коммита.

Reflog — это сокращение от журналов ссылок, которые записывают, когда в последний раз обновлялись подсказки ветвей и другие ссылки в локальном репозитории.

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

git reflog

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

Output
46f1962 HEAD@{0}: checkout: moving from branch-1 to new-branch
9370d03 HEAD@{1}: commit: code cleanups
a1f29a6 HEAD@{2}: commit: brand new feature 
38f2fc2 HEAD@{3}: commit: remove testing methods 
. . .

Сообщения о коммитах дадут вам знать, какой из коммитов вы оставили, а соответствующая строка будет перед информацией HEAD@{x} слева. стороны вашего окна терминала.

Теперь вы можете взять эту информацию и создать новую ветку из соответствующего коммита:

git checkout -b new-new-branch a1f29a6

В приведенном выше примере мы создали новую ветвь из третьего показанного выше коммита, который развернул «совершенно новую функцию», представленную строкой a1f29a6.

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

Примечание. Если вы недавно запускали команду git gc для очистки ненужных файлов и оптимизации локального репозитория, возможно, вы не сможете восстановить потерянные коммиты.

Чего ожидать от проверки кода

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

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

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

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

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

Принятие запроса на слияние и удаление вашей ветки

Если ваш запрос на включение был принят, вы успешно внесли свой вклад в проект программного обеспечения с открытым исходным кодом!

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

git checkout main
git pull --rebase origin main
git push -f origin main

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

git branch -d new-branch

Флаг -d, добавленный к команде git branch, удалит ветку, которую вы передаете команде. В приведенном выше примере он называется new-branch.

Далее мы удалим удаленную ветку:

git push origin --delete new-branch

Удалив ветки, вы очистили репозиторий, и ваши изменения теперь находятся в основном репозитории. Вы должны иметь в виду, что, поскольку изменения, внесенные вами с помощью запроса на вытягивание, теперь являются частью основного репозитория, они могут быть недоступны обычному конечному пользователю, загружающему публичные выпуски. Вообще говоря, специалисты по сопровождению программного обеспечения объединяют несколько новых функций и исправлений в один общедоступный выпуск.

Заключение

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

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