我不懂。我擅长于颠覆和比较繁琐的工作，但是当我尝试合并上游存储库中的更改并将结果推送到github上的fork时，我总是会遇到重复的提交，无意义的冲突，变基循环和其他意外结果。关于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 [email protected]:Charlweed/WorldEdit.git
cd WorldEdit
现在，按照github上的说明，我为父存储库设置了跟踪：
git remote add upstream [email protected]:sk89q/WorldEdit.git
最后，我尝试更新注册的子模块以匹配超级项目的期望：
git submodule update --init --recursive
这就是我“知道如何”设置的全部。我编写代码时一切都很好，并签入本地更改。当我将其推入github分支时，一切似乎都简单而简单。不幸的是，我一开始就感到困惑：
我拒绝在此详细说明我在工作流程中所做的错误事情：）。我应该怎么做才能跟上源回购，并有适合提交请求的整洁提交？
谢谢！
这就是我们管理开发周期的方式。http://nvie.com/posts/a-successful-git-branching-model/
真的没有幻想……我们每个人都在自己的分支上工作，每个分支都是一个功能。当功能的范围变得很大时，我们将它们分解成较小的部分，并在各自的分支中实现它们。在继续进行下一个之前，请确保我们合并分支。
该图看起来很复杂，但实际上显示的是只有两个永久分支。
您可以想象这样的分支...
master->development->feature_branch
像这样合并时...
master<-development<-feature_branch
因此，首先我们只有我们的master分支。然后，我们分支出一个与全球测试环境紧密结合的开发分支。最终，我们每个人都创建了自己的短命Feature_branch，并在自己的开发环境中对其进行了测试。
通过此工作流程，我们遵循三个规则
所有新功能分支都是从开发中创建的。完成后，它们将被合并回开发中……可以在其他任何新更改（可能是其他人同时编写）中对它们进行测试，并在一切正常的情况下最终将它们合并到master中。
现在，技术上的修补程序可以从master分支出来并快速实施，但随后需要将其合并到开发中。我个人更喜欢以与功能分支相同的方式来实现Bug修复，但这取决于您。
在开发新分支时，您可以通过SSH进入服务器（最好是开发环境）并切换到分支。 git checkout <branch-name>
您可能还需要git pull在第一次结帐之前先做一个事。同时git branch会告诉你，你是基于哪一个分支加列出的所有其他人。
一旦准备好部署，您只需将您的开发分支合并到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工作流程并对其进行修改以与项目一起使用。向作者询问它们通常如何进行，以便您可以知道应该从哪个分支分支。这样，您可以通过自己的稳定分支来实现更改，并且在准备就绪时可以提出拉取请求，以便作者可以查看您的更改。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句