Spec-Zone.ru › NumPy 1.20

Процесс разработки

У вас уже есть собственная форкнутая копия репозитория NumPy, следуя инструкциям Создать форк NumPy, Создать локальную копию, вы настроите git, следуя инструкциям Настройка Git, и свяжете удалённый репозиторий, как описано в Связывание вашего репозитория с удалённым.

Ниже описан рекомендуемый рабочий процесс с использованием Git.

Основной рабочий процесс

Вкратце:

  1. Для каждого набора изменений создайте новую ветвь разработки. См. ниже.
  2. Приступайте к работе! См. ниже
  3. После завершения:

    • Авторы: отправьте свою ветвь разработки в свой репозиторий на 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

Подробности

  1. Внесите изменения. Когда вы почувствуете, что сделали полный и рабочий набор связанных изменений, переходите к следующим шагам.
  2. Необязательно: Проверьте, какие файлы были изменены с помощью 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")
    
  3. Необязательно: Сравните изменения с предыдущей версией с помощью git diff (git diff). Это откроет простой текстовый браузер, который выделит различия между вашими файлами и предыдущей версией.
  4. Добавьте все соответствующие изменённые или новые файлы с помощью git add modified_file (см. git add). Это поместит файлы в область подготовки, которая является очередью файлов, которые будут добавлены в следующий коммит. Добавляйте только файлы с завершёнными связанными изменениями. Файлы с незавершенными изменениями оставьте для последующих коммитов.
  5. Чтобы закоммитить подготовленные файлы в локальную копию вашего репозитория, выполните git commit. На этом этапе откроется текстовый редактор, чтобы вы могли написать сообщение о коммите. Прочтите раздел сообщение о коммите, чтобы убедиться, что вы пишете правильно отформатированное и достаточно подробное сообщение о коммите. После сохранения сообщения и закрытия редактора, ваш коммит будет сохранён. Для тривиальных коммитов короткое сообщение о коммите можно передать через командную строку, используя флаг -m . Например, git commit -am "ENH: Some message".

    В некоторых случаях вы увидите такой вариант команды коммита: git commit -a. Дополнительный флаг -a автоматически коммитит все изменённые файлы и удаляет все удалённые файлы. Это может сэкономить вам время на ввод множества команд git add; однако, это может добавить ненужные изменения в коммит, если вы не внимательны. Для получения дополнительной информации, см. почему флаг -a? - и полезное описание использования в проблеме запутатой рабочей копии.

  6. Отправьте изменения в ваш форкнутый репозиторий на 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

Нажмите кнопку «Администрирование» и добавьте других людей в репозиторий в качестве соавторов:

../_images/pull_button.png

Теперь все эти люди могут:

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, а затем отправляете запрос на добавление ветки, содержащей бэкпортированные изменения.

  1. Сначала вам нужно создать ветку, на которой вы будете работать. Она должна основываться на более старой версии 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
    
  2. Теперь вам нужно применить изменения из 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
    
  3. При бэкпортировании вы можете столкнуться с конфликтами. Они решаются так же, как конфликты при слиянии/перебазировании. В этом случае вы можете использовать git blame, чтобы увидеть разницу между master и бэкпортированной веткой и убедиться, что ничего не сломалось.
  4. Отправьте новую ветку в ваш репозиторий на Github:

    git push -u origin backport-3324
    
  5. Наконец, создайте запрос на добавление, используя Github. Убедитесь, что он относится к ветке поддержки, а не к master, Github обычно предложит создать запрос на добавление к master.

Отправка изменений в основной репозиторий

Требуются права на коммиты в основной репозиторий NumPy.

Когда у вас есть набор «готовых» изменений в ветке функции, готовых для master или maintenance веток NumPy, вы можете отправить их в upstream следующим образом:

  1. Сначала выполните слияние или перебазирование на целевую ветку.

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

      git fetch upstream
      git rebase upstream/master
      

      См. Перебазирование на master.

    2. Если все коммиты связаны, создайте коммит слияния:

      git fetch upstream
      git merge --no-ff upstream/master
      
  2. Проверьте, что то, что вы собираетесь отправить, выглядит осмысленно:

    git log -p upstream/master..
    git log --oneline --graph
    
  3. Отправьте изменения в 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

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API