假设有一个名为Repo的存储库，并且有一些其他人制造的叉子。假设Repo是一些库或API。
当人们使用库/ API时，所有者会继续开发并在一段时间内添加功能并对现有功能进行改进。执行此类更新的正确程序是什么？我确信有人遵守，我目前还没有意识到。
在实施此类更新时是否应始终使用单独的分支？要做什么，如果一个人不知道这一点，愚蠢地继续推动主要分支的更新？
有没有办法通知用户（有分叉/克隆存储库的用户）更新？
我想学习现有的礼仪和程序，并遵守它们。
答案 0 :(得分：3)
这可能不是您问题的完整和良好的答案，但它的起点是您需要选择一个git工作流程。
我发现Atlassian的教程非常有用。 https://www.atlassian.com/git/tutorials/comparing-workflows
我所知道的一个简单的工作流程（至少可以完成您想要做的事情）是使用master / develop分支。
MASTER是你稳定的分支。 DEVELOP是您添加功能的分支。
当有人想要处理某个功能时，他会分支开发。他的变化是否会将他的变化合并到发展中。
像这样。
develop > git checkout -b featureX
featureX > touch README.md && git add . && git commit -m 'Add readme file'
featureX > git checkout develop
develop > git pull
develop > git checkout featureX
featureX > git rebase develop
featureX > git checkout develop
develop > git merge featureX
develop > git push origin develop
沿着这些方向发生了许多事情。人们可以在forked repo上的不同功能分支上同时工作（在develop分支中）。当他们做git rebase开发时，他们将所有新提交应用于他们开发分支的顶部（git pull将始终保持你的HEAD最近）。
一旦你做了一些重大改变，你可以使用git标记将HEAD /或某些提交标记为版本。然后将所有这些更改合并到主
中master> git merge develop
（这是您发布产品的下一个版本时）。
当然，在解释所有这些问题时，我可能错过了很多关键点，但我建议在顶部阅读Atlassian教程并主要依赖它而不是我的答案（这也是我从中学到的）。
还有一些其他git工作流程允许修复错误，如果将来你也希望合并它。
答案 1 :(得分：3)
通过阅读您的问题，我认为此API是一个开源项目。因此，我将告诉您处理贡献者的正常程序＆amp;版本
首先，为所有贡献者提供邮件列表是件好事。现在有一天人们使用Google群组作为邮件列表。因此，您的所有贡献者都可以订阅该邮件列表＆amp;你可以发一次消息。
开发开源项目的最佳做法是，
您可以在单独的分支中开发新功能，该分支将在下一版本中位于主服务器中。当您完成功能和＆amp;你很高兴与发布，合并该分支与主分支和＆amp;在那个时候标记主人，
git tag v0.1.1
git push --tags
并在邮件列表中发送一个发布说明，通知贡献者主人有新的提交。
通过这种方式，其他开发人员不会感到困惑和还告诉他们下一版本的API将在XXXXXXX分支中开发。因此，当您创建拉取请求时，请将其创建到该XXXXXXX分支。
在创建拉取请求之前，还告诉他们rebase他们的分支与您的存储库XXXXXXX分支
git pull --rebase upstream XXXXXXX
如果您不知道如何添加上游，
git add remote upstream YOUR-REPO-URL
答案 2 :(得分：2)