Процесс разработки
У вас уже есть собственная форкнутая копия репозитория NumPy, следуя инструкциям Создать форк NumPy, Создать локальную копию, вы настроите git, следуя инструкциям Настройка Git, и свяжете удалённый репозиторий, как описано в Связывание вашего репозитория с удалённым.
Ниже описан рекомендуемый рабочий процесс с использованием Git.
Основной рабочий процесс
Вкратце:
- Для каждого набора изменений создайте новую ветвь разработки. См. ниже.
- Приступайте к работе! См. ниже
-
После завершения:
- Авторы: отправьте свою ветвь разработки в свой репозиторий на Github и создайте запрос на слияние.
- Главные разработчики: Если вы хотите отправить изменения без дальнейшего рецензирования, см. заметки ниже.
Такой способ работы помогает организовать работу и сохранить историю изменений максимально ясной.
См. также
Существует множество онлайн-учебников, которые помогут вам освоить git. Для обсуждения конкретных рабочих процессов Git, смотрите эти обсуждения на linux git workflow и ipython git workflow.
Создание новой ветви разработки
Сначала получите новые коммиты из репозитория upstream:
git fetch upstream
Затем создайте новую ветвь, основанную на ветви master удалённого репозитория:
git checkout -b my-new-feature upstream/master
Процесс редактирования
Обзор
# hack hack git status # Optional git diff # Optional git add modified_file git commit # push the branch to your own Github repo git push origin my-new-feature
Подробности
- Внесите изменения. Когда вы почувствуете, что сделали полный и рабочий набор связанных изменений, переходите к следующим шагам.
-
Необязательно: Проверьте, какие файлы были изменены с помощью
git status(см. git status). Вы увидите список, похожий на этот:# On branch my-new-feature # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: README # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # INSTALL no changes added to commit (use "git add" and/or "git commit -a")
- Необязательно: Сравните изменения с предыдущей версией с помощью
git diff(git diff). Это откроет простой текстовый браузер, который выделит различия между вашими файлами и предыдущей версией. - Добавьте все соответствующие изменённые или новые файлы с помощью
git add modified_file(см. git add). Это поместит файлы в область подготовки, которая является очередью файлов, которые будут добавлены в следующий коммит. Добавляйте только файлы с завершёнными связанными изменениями. Файлы с незавершенными изменениями оставьте для последующих коммитов. -
Чтобы закоммитить подготовленные файлы в локальную копию вашего репозитория, выполните
git commit. На этом этапе откроется текстовый редактор, чтобы вы могли написать сообщение о коммите. Прочтите раздел сообщение о коммите, чтобы убедиться, что вы пишете правильно отформатированное и достаточно подробное сообщение о коммите. После сохранения сообщения и закрытия редактора, ваш коммит будет сохранён. Для тривиальных коммитов короткое сообщение о коммите можно передать через командную строку, используя флаг-m. Например,git commit -am "ENH: Some message".В некоторых случаях вы увидите такой вариант команды коммита:
git commit -a. Дополнительный флаг-aавтоматически коммитит все изменённые файлы и удаляет все удалённые файлы. Это может сэкономить вам время на ввод множества командgit add; однако, это может добавить ненужные изменения в коммит, если вы не внимательны. Для получения дополнительной информации, см. почему флаг -a? - и полезное описание использования в проблеме запутатой рабочей копии. -
Отправьте изменения в ваш форкнутый репозиторий на github:
git push origin my-new-feature
Для получения дополнительной информации, см. git push.
Примечание
Предполагается, что вы следовали инструкциям на этих страницах, и git создаст ссылку по умолчанию на ваш репозиторий на github, названный origin. В git >= 1.7 вы можете гарантировать постоянную связь с origin, используя опцию --set-upstream:
git push --set-upstream origin my-new-feature
Отныне git будет знать, что my-new-feature связан с веткой my-new-feature в вашем собственном репозитории на github. Последующие вызовы push упрощаются до следующего:
git push
Вы должны использовать --set-upstream для каждой новой ветви, которую вы создаёте.
Возможен случай, когда во время работы над изменениями в репозиторий upstream были добавлены новые коммиты, которые влияют на вашу работу. В этом случае, следуйте разделу Перебазирование на master этого документа, чтобы применить эти изменения к вашей ветви.
Создание сообщения о коммите
Сообщения о коммитах должны быть ясными и следовать нескольким основным правилам. Пример:
ENH: add functionality X to numpy.<submodule>. The first line of the commit message starts with a capitalized acronym (options listed below) indicating what type of commit this is. Then a blank line, then more text if needed. Lines shouldn't be longer than 72 characters. If the commit is related to a ticket, indicate that with "See #3456", "See ticket 3456", "Closes #3456" or similar.
Описание мотивации изменения, характера ошибки для исправлений ошибок или некоторых деталей, что делает улучшение, также хорошо включать в сообщение о коммите. Сообщения должны быть понятны без просмотра кода. Сообщение о коммите, например, MAINT: fixed another one — пример того, чего не следует делать; читателю необходимо искать контекст где-то ещё.
Стандартные аббревиатуры для начала сообщения о коммите:
API: an (incompatible) API change BENCH: changes to the benchmark suite BLD: change related to building numpy BUG: bug fix DEP: deprecate something, or remove a deprecated object DEV: development tool or utility DOC: documentation ENH: enhancement MAINT: maintenance commit (refactoring, typos, etc.) REV: revert an earlier commit STY: style fix (whitespace, PEP8) TST: addition or modification of tests REL: related to releasing numpy
Получите мнение списка рассылки
Если вы планируете новое изменение или изменение API, разумнее всего сначала написать электронное письмо на список рассылки NumPy mailing list и попросить комментарии. Если вы не получите ответа в течение недели, можно снова написать.
Запрос на слияние ваших изменений с основным репозиторием
Когда вы почувствуете, что ваша работа завершена, вы можете создать запрос на слияние (PR). Github имеет отличную страницу справки, которая описывает процесс создания запросов на слияние.
Если ваши изменения включают изменения API или добавление/изменение функции, добавьте примечание к релизу в каталог doc/release/upcoming_changes/, следуя инструкциям и формату в файле doc/release/upcoming_changes/README.rst.
Обзор вашего запроса на слияние
Мы рассматриваем запросы на слияние как можно быстрее, обычно в течение недели. Если вы не получите комментарии в течение двух недель, можете запросить обратную связь, добавив комментарий к вашему запросу на слияние (это уведомит администраторов).
Если ваш запрос на слияние большой или сложный, полезно запросить вход на списке рассылки numpy-discussion.
Перебазирование на master
Это обновляет вашу ветвь разработки с изменениями из удалённого репозитория NumPy на github. Если вам не нужно это делать, постарайтесь избегать этого, за исключением, возможно, тех случаев, когда вы завершили работу. На первом шаге необходимо обновить удалённый репозиторий новыми коммитами из upstream:
git fetch upstream
Далее необходимо обновить ветвь разработки:
# go to the feature branch git checkout my-new-feature # make a backup in case you mess up git branch tmp my-new-feature # rebase on upstream master branch git rebase upstream/master
Если вы внесли изменения в файлы, которые также изменились в upstream, это может создать конфликты слияния, которые необходимо разрешить. См. раздел ниже для помощи в этом случае.
Наконец, удалите резервную ветвь после успешного перебазирования:
git branch -D tmp
Примечание
Перебазирование на master предпочтительнее слияния upstream обратно в вашу ветвь. Использование git merge и git pull не рекомендуется при работе с ветвями разработки.
Восстановление после ошибок
Иногда вы допускаете ошибки при слияниях или перебазировании. К счастью, в Git относительно просто исправить такие ошибки.
Если вы допустили ошибку во время перебазирования:
git rebase --abort
Если вы заметили ошибку после перебазирования:
# reset branch back to the saved point git reset --hard tmp
Если вы забыли создать резервную ветвь:
# look at the reflog of the branch
git reflog show my-feature-branch
8630830 my-feature-branch@{0}: commit: BUG: io: close file handles immediately
278dd2a my-feature-branch@{1}: rebase finished: refs/heads/my-feature-branch onto 11ee694744f2552d
26aa21a my-feature-branch@{2}: commit: BUG: lib: make seek_gzip_factory not leak gzip obj
...
# reset the branch to where it was before the botched rebase
git reset --hard my-feature-branch@{2}
Если вы не допустили ошибки, но есть конфликты слияния, вам нужно разрешить их. Это может быть одна из более сложных вещей для освоения. Для хорошего описания этого, см. статью о конфликтах слияния.
Дополнительные действия, которые могут потребоваться
Переписывание истории коммитов
Примечание
Делайте это только для ваших собственных ветвей разработки.
В коммите есть нелепая ошибка? Или, возможно, вы сделали несколько ложных попыток, которые вы бы хотели скрыть от потомков.
Это можно сделать с помощью интерактивного перебазирования.
Предположим, что история коммитов выглядит так:
git log --oneline eadc391 Fix some remaining bugs a815645 Modify it so that it works 2dec1ac Fix a few bugs + disable 13d7934 First implementation 6ad92e5 * masked is now an instance of a new object, MaskedConstant 29001ed Add pre-nep for a couple of structured_array_extensions. ...
и 6ad92e5 — последний коммит в ветви master. Предположим, что мы хотим внести следующие изменения:
- Перепишите сообщение коммита для
13d7934на что-нибудь более осмысленное. - Объедините коммиты
2dec1ac,a815645,eadc391в один.
Мы делаем следующее:
# make a backup of the current state git branch tmp HEAD # interactive rebase git rebase -i 6ad92e5
Это откроет редактор с указанным ниже текстом:
pick 13d7934 First implementation pick 2dec1ac Fix a few bugs + disable pick a815645 Modify it so that it works pick eadc391 Fix some remaining bugs # Rebase 6ad92e5..eadc391 onto 6ad92e5 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # # If you remove a line here THAT COMMIT WILL BE LOST. # However, if you remove everything, the rebase will be aborted. #
Чтобы добиться желаемого результата, мы внесём в него следующие изменения:
r 13d7934 First implementation pick 2dec1ac Fix a few bugs + disable f a815645 Modify it so that it works f eadc391 Fix some remaining bugs
Это означает, что (i) мы хотим отредактировать сообщение коммита для 13d7934, и (ii) объединить последние три коммита в один. Теперь сохраняем и выходим из редактора.
Git немедленно откроет редактор для изменения сообщения коммита. После его пересмотра, мы получим результат:
[detached HEAD 721fc64] FOO: First implementation 2 files changed, 199 insertions(+), 66 deletions(-) [detached HEAD 0f22701] Fix a few bugs + disable 1 files changed, 79 insertions(+), 61 deletions(-) Successfully rebased and updated refs/heads/my-feature-branch.
и история теперь будет выглядеть так:
0f22701 Fix a few bugs + disable 721fc64 ENH: Sophisticated feature 6ad92e5 * masked is now an instance of a new object, MaskedConstant
Если что-то пошло не так, восстановление возможно, как описано выше.
Удаление ветки на github
git checkout master # delete branch locally git branch -D my-unwanted-branch # delete branch on github git push origin --delete my-unwanted-branch
См. также: https://stackoverflow.com/questions/2003505/how-do-i-delete-a-git-branch-locally-and-remotely
Несколько человек, работающих с одним репозиторием
Если вы хотите поработать над чем-то с другими людьми, где вы все делаете коммиты в один и тот же репозиторий, или даже в одну и ту же ветку, просто поделитесь им через github.
Сначала создайте форк NumPy в вашей учётной записи, как описано в создании форка NumPy.
Затем перейдите на страницу вашего форкнутого репозитория на github, например, https://github.com/your-user-name/numpy
Нажмите кнопку «Администрирование» и добавьте других людей в репозиторий в качестве соавторов:
Теперь все эти люди могут:
git clone git@github.com:your-user-name/numpy.git
Помните, что ссылки, начинающиеся с git@, используют протокол ssh и являются чтением/записью; ссылки, начинающиеся с git://, предназначены только для чтения.
Ваши соавторы затем могут делать коммиты непосредственно в этот репозиторий с помощью обычных команд:
git commit -am 'ENH - much better code' git push origin my-feature-branch # pushes directly into your repo
Изучение вашего репозитория
Чтобы увидеть графическое представление веток и коммитов репозитория:
gitk --all
Чтобы увидеть линейный список коммитов для этой ветки:
git log
Вы также можете посмотреть визуализатор сети для вашего github репозитория.
Бэкпортирование
Бэкпортирование — это процесс копирования новых функций/исправлений, внесённых в numpy/master, обратно в стабильные ветки выпусков. Для этого вы создаёте ветку из той ветки, в которую бэкпортите, выбираете нужные коммиты из numpy/master, а затем отправляете запрос на добавление ветки, содержащей бэкпортированные изменения.
-
Сначала вам нужно создать ветку, на которой вы будете работать. Она должна основываться на более старой версии NumPy (не master):
# Make a new branch based on numpy/maintenance/1.8.x, # backport-3324 is our new name for the branch. git checkout -b backport-3324 upstream/maintenance/1.8.x
-
Теперь вам нужно применить изменения из master к этой ветке, используя git cherry-pick:
# Update remote git fetch upstream # Check the commit log for commits to cherry pick git log upstream/master # This pull request included commits aa7a047 to c098283 (inclusive) # so you use the .. syntax (for a range of commits), the ^ makes the # range inclusive. git cherry-pick aa7a047^..c098283 ... # Fix any conflicts, then if needed: git cherry-pick --continue
- При бэкпортировании вы можете столкнуться с конфликтами. Они решаются так же, как конфликты при слиянии/перебазировании. В этом случае вы можете использовать git blame, чтобы увидеть разницу между master и бэкпортированной веткой и убедиться, что ничего не сломалось.
-
Отправьте новую ветку в ваш репозиторий на Github:
git push -u origin backport-3324
- Наконец, создайте запрос на добавление, используя Github. Убедитесь, что он относится к ветке поддержки, а не к master, Github обычно предложит создать запрос на добавление к master.
Отправка изменений в основной репозиторий
Требуются права на коммиты в основной репозиторий NumPy.
Когда у вас есть набор «готовых» изменений в ветке функции, готовых для master или maintenance веток NumPy, вы можете отправить их в upstream следующим образом:
-
Сначала выполните слияние или перебазирование на целевую ветку.
-
Если есть несколько, не связанных между собой коммитов, то лучше использовать перебазирование:
git fetch upstream git rebase upstream/master
-
Если все коммиты связаны, создайте коммит слияния:
git fetch upstream git merge --no-ff upstream/master
-
-
Проверьте, что то, что вы собираетесь отправить, выглядит осмысленно:
git log -p upstream/master.. git log --oneline --graph
-
Отправьте изменения в upstream:
git push upstream my-feature-branch:master
Примечание
Обычно рекомендуется использовать флаг -n для git push , чтобы предварительно проверить, что вы собираетесь отправить нужные изменения в нужное место.
© 2005–2021 NumPy Developers
Licensed under the 3-clause BSD License.
https://numpy.org/doc/1.20/dev/development_workflow.html