Git:多分支部署工作流

Git:多分支部署工作流,git,bitbucket,Git,Bitbucket,我试图了解在使用多个分支(每个分支都将部署到特定环境)时,如何最好地改进我的工作流 让我们从使用BitBucket托管git存储库开始,我在它上面有三个分支:origin/master、origin/staging和origin/production 每当我完成一项新任务时,我都会将任务提交到本地分支master,然后将其推送到origin/master。在此之后,如果我想部署提交到暂存,我只需打开分支并运行“同步”(使用BitBucket功能),以便分支origin/staging与origi

我试图了解在使用多个分支(每个分支都将部署到特定环境)时,如何最好地改进我的工作流

让我们从使用BitBucket托管git存储库开始,我在它上面有三个分支:
origin/master
origin/staging
origin/production

每当我完成一项新任务时,我都会将任务提交到本地分支
master
,然后将其推送到
origin/master
。在此之后,如果我想部署提交到暂存,我只需打开分支并运行“同步”(使用BitBucket功能),以便分支
origin/staging
origin/master
匹配

但是,当我查看SourceTree上的存储库时,感觉自己搞砸了,这可能不是正确的方法

这是存储库在SourceTree上的外观:

这就是它在BitBucket上的外观:

首先:为什么说
origin/production
origin/staging
分别比
origin/master
提前4次和6次提交


其次,如果我所做的是错误的/可以改进的,您会建议我做什么?

生产
暂存
位于您的
分支之前,因为在
中不存在合并提交。您可以在SourceTree屏幕截图中很容易地看到这一点:
origin/production
是在master之前的四次(合并)提交,这四次提交带有
Merged master to production
消息。这与您的
staging
分支类似


之所以会出现这种情况,是因为您反复将
主分支
分支合并到其他分支中,但从未将其他分支合并回主分支。这没有错。只要“前进”计数不打扰你,你就一切就绪。如果您希望在
主控
之前没有提交,您可以将
生产
暂存
合并回主控。这不会更改您的任何数据,合并提交也将成为您的
主记录的一部分。

我认为您的工作流没有问题。SourceTree图形看起来比必要的更复杂,但如果仔细跟踪所有行,您将看到它与BitBucket显示的图形完全相同。感谢您的解释,它帮助了我:)