维护派生的git仓库的工作流程是什么？

Question

我不懂。 我能胜任Subversion和Mercury的工作，但是当我尝试合并上游存储库中的更改并将结果推送到github上的fork时，我总是遇到重复的提交，无意义的冲突，rebase循环以及其他意外结果。 这里关于stackoverflow的其他答案没有提到使用git remote add upstream而且似乎缺少我需要停止失败的细节。

例如，假设我从https://github.com/sk89q/WorldEdit上的github存储库WorldEdit开始，在github上，我将存储库分叉到https://github.com/Charlweed/WorldEdit现在将其克隆到Linux或Cygwin上的本地工作站。 我使用–recursive选项，因为WorldEdit似乎具有三个子模块。 git clone --recursive git@github.com:Charlweed/WorldEdit.git

cd WorldEdit

现在，按照github上的说明，我为父存储库设置了跟踪：

git remote add upstream git@github.com:sk89q/WorldEdit.git

最后，我尝试更新注册的子模块以匹配超级项目的期望：

git submodule update --init --recursive

这就是我“知道如何”设置的全部。 我编写代码时一切都很好，并签入本地更改。 当我将其推入github分支时，一切似乎都简单而简单。 不幸的是，我一开始就困惑：

1. 将原来的父github存储库中的更改合并到我的派生github存储库中。
2. 将我的许多小型本地提交“重新设置”为单个提交。

我拒绝在这里详细说明我在工作流程中做的错误的事情：）。 我应该怎么做才能跟上源回购，并有适合提交请求的整洁提交？

谢谢！

Answer 1

GIT开发

这就是我们管理开发周期的方式。 http://nvie.com/posts/a-successful-git-branching-model/

真的没有幻想……我们每个人都在自己的分支机构工作，每个分支机构都是一个功能。 当功能的范围变得很大时，我们将它们分解为较小的部分，并在各自的分支中实现它们。 在继续下一个之前，请确保我们合并分支。

该图看起来很复杂，但实际上显示的是只有两个永久分支。

1. 发展
2. 主

您可以想象这样的分支...

master->development->feature_branch

像这样合并时...

master<-development<-feature_branch

因此，首先我们只有主分支。 然后，我们分支出一个与全球测试环境紧密结合的开发分支。 最终，我们每个人都创建了自己的短暂Feature_branch ，并在自己的开发环境中对其进行了测试。

通过此工作流程，我们遵循三个规则

1. 永远不要直接提交给主人
2. 永远不要直接致力于发展
3. 始终从新的SHORT-LIVED分支实施功能

特征

所有新功能分支都是从开发中创建的。 完成后，将它们合并回开发中 ……可以在其他任何新更改（可能是其他人同时编写）中对它们进行测试，并在一切正常的情况下最终将它们合并到master中 。

修复

现在，技术上的修补程序可以从master分支出来并快速实施，但随后需要将其合并到开发中 。 我个人更喜欢以与功能分支相同的方式来实现Bug修复，但这取决于您。

测试

在开发新分支时，可以通过SSH进入服务器（最好是开发环境）并切换到分支。 git checkout <branch-name>

您可能还需要在首次签出之前进行git pull 。 git branch还会告诉您您在哪个分支上，并列出所有其他分支。

GIT部署

准备好部署后，只需将您的开发分支合并到master中，然后提交并推送更改。 然后通过SSH连接到服务器（实时）并执行git pull。 为了清晰起见，您无需在登录服务器时使用pull以外的任何其他git cmd。 难得的案例当然没有。

这个想法是您的生产服务器应该与master分支紧密耦合。 换句话说，永远不要在此服务器上使用git checkout <branch> 。

工具

这完全由您决定，但是我们的团队更喜欢使用Windows GUI工具sourcetree。 https://www.sourcetreeapp.com/

如果您更喜欢CMD行，那很好。 该文档帮助我学习了CMD的一些基础知识。 http://rogerdudler.github.io/git-guide/

大多数时候，GIT和SourceTree处理合并冲突确实很好。 但是有时您需要一个3向差异工具来提供帮助...我强烈建议Kdiff http://kdiff3.sourceforge.net/

它与SourceTree集成在一起，可以处理一些非常复杂的合并问题。 如果做正确的事，您可能永远都不需要。

同步叉子

现在，要记住Forked回购协议。 在尝试遵循正常的工作流程之前，您需要确保将一致的上游更改/合并到您的仓库中。 https://help.github.com/articles/syncing-a-fork/

执行此操作时， 强烈建议您没有上游存储库没有的未完成提交。 如果这样做，那么您需要发出请求请求……当然，这是假定这些提交已准备好提交。 （有关更多特定规则，请参见报价） https://help.github.com/articles/using-pull-requests/

@JBNizet很有意思！

永远不要在上游存储库中已经存在的分支中工作（例如，主服务器）。 创建自己的作品并在其中工作。 定期从上游更新master分支（它应该总是快进），并定期在master上重新建立自己的分支。 准备就绪后，将分支请求从分支发送到上游主分支

如果我们考虑这些词，那么您可以采用此std工作流程并对其进行修改以与项目一起使用。 向作者询问它们通常如何进行，以便您知道应该从哪个分支分支。 这样，您可以通过自己的稳定分支来实现更改，并且在准备就绪时可以提出拉取请求，以便作者可以查看您的更改。