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

Вступление

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

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

Предпосылки

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

Чтобы узнать больше о вкладе в проекты с открытым исходным кодом, вы можете прочитатьthis introduction. Чтобы узнать о том, как делать запросы на извлечение, вы можете прочитать «https://www.digitalocean.com/community/tutorials/how-to-create-a-pull-request-on-github[How Создание запроса на извлечение на GitHub] «.

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

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

Или вот так по вашему запросу на сайте GitHub:

GitHub pull request conflicts

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

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

Как и в случае сpull request tutorial, мы перейдем в каталог кода и получим самую последнюю версию кода из исходной версии.

cd repository
git fetch upstream

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

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

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

git log

Это даст вам вывод, который выглядит примерно так:

Outputcommit 46f196203a16b448bf86e0473246eda1d46d1273
Author: username-2 
Date:   Mon Dec 14 07:32:45 2015 -0400

    Commit details

commit 66e506853b0366c87f4834bb6b39d941cd034fe3
Author: username1 
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 master

Эта команда вернет длинную строку, известную как хеш коммита, примерно такой:

Output66e506853b0366c87f4834bb6b39d341cd094fe9

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

git rebase -i 66e506853b0366c87f4834bb6b39d341cd094fe9

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

Сквош

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

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

Файл GNU nano 2.0.6:… имя пользователя / репозиторий / .git / rebase-merge / git-rebase-todo

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

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

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

Файл GNU nano 2.0.6:… имя пользователя / репозиторий / .git / rebase-merge / git-rebase-todo

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

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

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

OutputSuccessfully rebased and updated refs/heads/new-branch.

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

Reword Commits

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

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

Файл GNU nano 2.0.6:… имя пользователя / репозиторий / .git / rebase-merge / git-rebase-todo

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

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

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

Файл GNU nano 2.0.6:… имя пользователя / репозиторий / .git / rebase-merge / git-rebase-todo

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

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

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

Завершите ребаз

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

git rebase upstream/master

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

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

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
OutputAlready on 'new-branch'
. . .

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

git push -f

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

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

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

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

Reflog - это сокращение отreference logs, которое записывает, когда кончики веток и другие ссылки были в последний раз обновлены в локальном репозитории.

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

git reflog

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

Output46f1962 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.

В зависимости от того, что вам нужно сделать отсюда, вы можете выполнить шаги по настройке вашей ветки вthis tutorial on pull requests или вернуться вtop of the current tutorial, чтобы работать, перебазировав новую ветку.

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

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

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

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

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

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

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

Подтверждение запроса на удаление и удаление вашего филиала

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

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

git checkout master
git pull --rebase upstream master
git push -f origin master

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

git branch -d new-branch

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

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

git push origin --delete new-branch

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

Заключение

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

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

Related