我在许多开发人员的几个项目中使用git。我通常的工作流程是在本地分支以获取特定功能/请求，将我的更改合并到上游跟踪的本地分支作为快进合并，并推送更改。我总是为一个提交分支。我不会在我与其他人共享的分支上进行本地提交，因此我可以自由地在本地进行重新设置/删除，直到我将更改推送到上游。作为优先选择，我希望我的合并尽可能快速提交。例如，如果origin/v1分支上的所有开发人员都推送了项目的第1版，那么我会：
git checkout v1
git checkout -b feature-A
#Do work on feature-A branch. Test, rebase --interactive to clean up
最终我想在本地将我的更改合并到v1并推送到origin/v1。我会签出git fetch origin签出feature-A。如果进行了更改，我将结帐v1并合并
git fetch origin
#If New changes are present checkout v1 and merge
git checkout v1
git merge origin/v1 #I could pull but I prefer to fetch, log origin/v1, and then merge
现在实现feature-A的快进合并，我结帐feature-A，重新绑定到v1，结帐v1，合并feature-A，然后推送{{ 1}}返回v1。
origin非快进提交没有任何问题，合并提交没有任何问题。同样，这只是一个偏好问题。我想知道是否有更好的工作流程来完成同样的事情而不经过分支机构的所有结账。可能有一个我不知道的git命令在我在更新的git checkout feature-A
git rebase v1
git checkout v1
git merge --ff-only feature-A
git push origin v1
分支之上重新feature-A之后会起作用。
https://stackoverflow.com/a/4157106/620304看起来可能有所帮助。可能的工作流程是使用来自源的最新更改来更新v1，并在我重新定义后在本地更新v1到v1的HEAD：
feature-A我确信可能会有更好的方法。非常感谢任何帮助/意见。
答案 0 :(得分：2)
仅使用快进合并的工作流本质上是一个rebase工作流。一般的rebase工作流程与您给出的示例非常相似，除了git rebase origin/v1而不是合并。
我看到的参考文章最多的是Randy Fay的博文：A Rebase Workflow for Git。
请务必阅读本文开头链接的后续文章，了解一些简短的内容，以便于使用。