我们有gerrit（在服务器上提供服务，并且repo的路径是/ a_repo，因此git remote -v返回origin ssh://user@server:PORT/a_repo）基于工作流程，这是 - 任何在项目之后工作的人
git clone ssh://user@server/a_repo和git checkout fancy/named/branch 需要
修改并提交更改git commit -a -m "COMMIT_MSG"
推送更改以git push origin HEAD:refs/for/fancy/named/branch进行审核（因为我希望对其进行审核，以防我没有推送到 HEAD：refs / heads / fancy / named /分支或 HEAD：refs / fancy / named / branch ？）
git fetch -a表示origin / fancy / named / branch和fancy / named / branch有不同的提交。 此问题的一个解决方案是临时切换到另一个分支，删除旧的git -D fancy/named/branch并再次执行git co fancy/named/branch ...这将创建基于来自原始分支的新分支。但我发现这很麻烦，并且反对我对git工作流程的看法。
其他解决方案是改变＆fancy / named / branch＆＃39; on＆＃39; origin / fancy / named / branch＆＃39; （git co fancy/named/branch && git rebase origin/fancy/named/branch）？
这也有效，但我不相信它是完全安全的。
我一直试图在this和gerrit_server/gerrit/Documentation的帮助下抓住格里特的方法，但似乎无法理解它以及正常的＃39;基于git的操作和工作流程。
我该如何改进？我应该担心吗？
EDIT。
实际上考虑到这个问题，这是一个愚蠢的问题。但如果其他人有类似疑虑，我不会删除它。为什么这么傻？
实际上，在提交和发出推送之后，进程与普通的git工作流没有太大区别 - 通常你需要进行rebase或merge（如果有人推到你旁边的这个分支）。
但是，不要完全浪费这个问题 - 也许有人可以澄清
之间的区别git push HEAD:refs/heads/fancy/name/branch和git push HEAD:refs/fancy/named/branch 在gerrit相关工作流程方面？ （虽然简单＆＃34;对于＆＃34;在refs/for/branch中会导致提交进行审核过程，上面两个例子怎么样？）