开发工作流

您已经有了自己的分支副本 scikit-image 存储库，通过以下方式 制作您自己的SCRKIT-IMAGE副本(分叉) 。你有 摆好你的叉子 。您已经通过以下方式配置了GIT 配置GIT 。现在你已经准备好做一些真正的工作了。

工作流程摘要

在接下来的内容中，我们将引用上游SCRKIT-IMAGE master 树枝，即“树干”。

  • 不要用你的 master 分支机构做任何事。考虑删除它。

  • 当您开始一组新的更改时，从主干获取任何更改，然后开始一个新的 功能分支 从那开始。

  • 为每组可拆分的更改创建一个新分支 — 一项任务，一个分支 (ipython git workflow )。

  • 根据更改的目的命名您的分支机构--例如 bugfix-for-issue-14 或 refactor-database-code 。

  • 如果可以避免，请避免在工作时将主干或任何其他分支合并到功能分支中。

  • 如果您确实发现自己正在从主干合并，请考虑 基于主干重新建立基础

  • 在网上询问 scikit-image mailing list 如果你被卡住了。

  • 请求代码审查！

这种工作方式有助于保持工作的良好组织，具有可读的历史。这反过来使项目维护人员(可能是您)更容易看到您做了什么，以及为什么要这样做。

看见 linux git workflow 和 ipython git workflow 寻求一些解释。

考虑删除您的主分支机构

这可能听起来很奇怪，但删除你自己的 master 分支机构可以帮助减少对您所在分支机构的困惑。看见 deleting master on github 有关详细信息，请参阅。

更新主干的镜像

首先，确保您已经完成了 将存储库链接到上游回购 。

您应不时从GitHub：：获取上游(主干)更改

git fetch upstream

这将拉下您没有的所有提交，并将远程分支设置为指向正确的提交。例如，主干是(远程/分支名称)引用的分支 upstream/master -如果自上次检查后有提交， upstream/master 在您执行取回操作后将会发生变化。

创建新的要素分支

当您准备好对代码进行一些更改时，您应该开始一个新的分支。用于相关编辑集合的分支通常称为“要素分支”。

为每一组相关更改创建一个新分支将使查看您的分支的人更容易看到您在做什么。

为分支机构选择一个信息丰富的名称，以提醒您自己和我们其他人分支机构中的更改是为了什么。例如 add-ability-to-fly ，或 buxfix-for-issue-42 。

# Update the mirror of trunk
git fetch upstream
# Make new feature branch starting at current trunk
git branch my-new-feature upstream/master
git checkout my-new-feature

通常，您会希望将您的功能分支保持在公共位置 github 叉子 scikit-image 。要做到这一点，你 git push 这个新的分支一直到您的GitHub回购。通常(如果您按照这些页面中的说明操作，默认情况下)，Git会有一个指向您的GitHub Repo的链接，名为 origin 。您可以通过以下方式在GitHub上推送您自己的回购：

git push origin my-new-feature

在git>=1.7中，您可以通过使用 --set-upstream 选项：：

git push --set-upstream origin my-new-feature

从现在开始，git会知道 my-new-feature 与 my-new-feature GitHub回购中的分支。

编辑工作流

概述

# hack hack
git add my_new_file
git commit -am 'NF - some message'
git push

更详细地说

  1. 做一些改变

  2. 查看哪些文件已更改 git status (请参阅 git status )。您将看到如下所示的列表：：

    # On branch ny-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. Check what the actual changes are with git diff (git diff).

  4. 将任何新文件添加到版本控制 git add new_file_name (请参阅 git add )。

  5. To commit all modified files into the local copy of your repo,, do git commit -am 'A commit message'. Note the -am options to commit. The m flag just signals that you're going to type a message on the command line. The a flag — you can just take on faith — or see why the -a flag? — and the helpful use-case description in the tangled working copy problem. The git commit manual page might also be useful.

  6. 要将更改推送到GitHub上的分叉回购，请执行a git push (请参阅 git push )。

请求查看或合并您的更改

当您准备请求某人审阅您的代码并考虑合并时：

  1. 转到您的分叉回购的URL，比如 https://github.com/your-user-name/scikit-image 。

  2. 使用页面左上角附近的“切换分支”下拉菜单选择所做更改的分支：

    ../_images/branch_dropdown.png

  3. 点击“Pull Request”按钮：

    ../_images/pull_button.png

    输入更改集的标题，以及对您所做操作的一些解释。如果有什么需要特别注意的--比如复杂的更改或您不满意的代码，请说出来。

    如果您认为您的请求尚未准备好合并，请在您的Pull请求消息中说明这一点。这仍然是获得一些初步代码审查的好方法。

您可能还想做一些其他的事情

删除GitHub上的分支

git checkout master
# delete branch locally
git branch -D my-unwanted-branch
# delete branch on github
git push origin :my-unwanted-branch

(请注意冒号 : 在此之前 test-branch 。另请参阅：https://help.github.com/en/github/using-git/managing-remote-repositories

几个人共享一个存储库

如果你想和其他人一起工作，你们都提交到同一个库，甚至同一个分支，那么只需通过GitHub共享它。

第一个分叉SCRKIT-镜像到您的帐户，如来自 制作您自己的SCRKIT-IMAGE副本(分叉) 。

然后，转到您的分叉存储库GitHub页面，比如 https://github.com/your-user-name/scikit-image

点击‘Admin’按钮，然后将其他任何人作为协作者添加到回购：

../_images/pull_button.png

现在所有这些人都可以做：：

git clone git@githhub.com:your-user-name/scikit-image.git

请记住，以 git@ 使用ssh协议，并且是读写的；链接以 git:// 是只读的。

然后，您的协作者可以使用通常的以下内容直接提交该回购：

git commit -am 'ENH - much better code'
git push origin master # pushes directly into your repo

浏览您的存储库

要查看存储库分支和提交的图形表示，请执行以下操作：

gitk --all

要查看此分支的提交线性列表，请执行以下操作：

git log

您还可以查看 network graph visualizer 用于您的GitHub回购。

最后是 花式原木输出 lg Alias将为您提供一个合理的基于文本的存储库图形。

基于主干重新建立基础

比方说，你想到了一些你想做的工作。你 更新主干的镜像 和 创建新的要素分支 被叫 cool-feature 。在此阶段，主干处于某个提交状态，我们将其命名为E。现在，您将在 cool-feature BRANCH，我们称它们为A、B、C。也许您的更改需要一段时间，或者一段时间后您会返回到它们。同时，Trunk已经从提交E前进到提交(比如)G：：

      A---B---C cool-feature
     /
D---E---F---G trunk

在这个阶段，您考虑将主干合并到您的Feature分支中，并且您还记得这里的页面强烈建议您不要这样做，因为历史会变得混乱。大多数情况下，您只需要求进行审查，而不必担心Track已经领先了一点。但有时，主干中的更改可能会影响您的更改，您需要协调它们。在这种情况下，你可能更喜欢做一次改垒。

Rebase接受您的更改(A、B、C)并重放它们，就像它们已被设置为当前状态一样 trunk 。换句话说，在本例中，它获取由A、B、C表示的更改，并在G上重放它们。在重新基址之后，您的历史将如下所示：

              A'--B'--C' cool-feature
             /
D---E---F---G trunk

看见 rebase without tears 了解更多详细信息。

要在主干上执行重新基址：：

# Update the mirror of trunk
git fetch upstream
# go to the feature branch
git checkout cool-feature
# make a backup in case you mess up
git branch tmp cool-feature
# rebase cool-feature onto trunk
git rebase --onto upstream/master upstream/master cool-feature

在这种情况下，您已经在分支机构上 cool-feature ，最后一个命令可以更简洁地写为：：

git rebase upstream/master

当一切正常时，您可以删除备份分支：：

git branch -D tmp

如果它看起来不太好，你可能需要看看 从混乱中恢复过来 。

如果您对主干中也已更改的文件进行了更改，这可能会生成需要解决的合并冲突-请参阅 git rebase 手册页，查看“Description”部分末尾的一些说明。Git用户手册中有一些关于合并的相关帮助，请参阅 resolving a merge 。

从混乱中恢复过来

有时，你会搞砸合并或重新部署。幸运的是，在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 cool-feature

8630830 cool-feature@{0}: commit: BUG: io: close file handles immediately
278dd2a cool-feature@{1}: rebase finished: refs/heads/my-feature-branch onto 11ee694744f2552d
26aa21a cool-feature@{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 cool-feature@{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 copule of structured_array_extensions.
...

和 6ad92e5 中的最后一次提交。 cool-feature 布兰奇。假设我们要进行以下更改：

  • 重写以下内容的提交消息 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

如果它出了问题，正如所解释的那样，恢复是可能的。 above 。