我有两个分支：
在部署中推送某些内容时，构建系统会自动部署更改。所以平时的工作是在各部门完成，合并到主，然后，当它的时间来部署，主合并到部署和工作的事情。
由于deploy实际上除了master之外没有任何常规合并，因此我在考虑尝试使用rebase而不是merge。
我的理解是：
git checkout master
git rebase deploy
和..什么都没有发生
这是输出：
$ git checkout master
Already on 'master'
Your branch is up to date with 'origin/master'.
$ git rebase deploy
Current branch master is up to date.
显然，该功能有效，我不了解：)我缺少了什么？
也许这不是实现我目标的正确方法；简而言之，我试图使它像这样：部署负责人现在指向master负责人。
假设deploy永远不会直接提交给您，并且只会收到来自master...的合并
合并新功能（E-F-G-H）之后，在部署新功能之前，您的仓库看起来像这样。
B - C E - F - G - H
/ \ / \
A ----- D ------------- I [master]
[deploy]
您可以用来git log --graph --decorate在自己的存储库中查看此结构，但会垂直翻转。
请注意deployD处直接master在I处。当您将master合并到deploy时，不需要进行合并，因此Git会执行“快进”并将deploy标签移动到与相同的提交master。
git checkout deploy
git merge master
B - C E - F - G - H
/ \ / \
A ----- D ------------- I [master] [deploy]
master而deploy现在点同时提交。
当您尝试在重新构建master基础之上进行重新deploy构建时，却无所事事。
附带说明一下deploy，此工作流程中几乎不需要分支，因为deploy它始终是的直接祖先master。由于您只是在现有合并周围移动标签，因此使用标签来标记要部署的提交会更简单。
# Move the deploy tag to master.
git tag -f deploy master
这也使撤消部署变得更加容易。假设最新功能已被删除。修复它时，可以将标签移回先前已知的良好提交。
# Roll back deployment to commit ABC123
git tag -f deploy ABC123
您可以使用带编号，带有时间戳或带有版本的标签来跟踪发布并发布最高的版本。
git tag v1.2.3 master
# Get the newest version
git tag --sort=-v:refname | head -1
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句