Git流-管理主与开发之间的差异 [英] Git flow - managing differences between master and develop

问题描述

我已经使用Git Flow已有一段时间了，但是在最初的一周左右，我是从master手动创建release分支的，而Cherry则将所需的提交选择到release分支中，而不是从master进行创建.

I've been using Git Flow for a little while now, however in the initial week or so I was creating release branches manually from master and cherry picking the required commits into the release branch rather than creating them from master.

例如，如果我在开发分支中提交了abcd123 My commit message，我还手动将其樱桃放入了release分支中，此时，我可能已经修改或编辑了提交消息，因此release分支(和现在是master分支)包含此提交但具有不同的哈希，例如dbca321 My adjusted commit message.

For example, if I have commit abcd123 My commit message in the develop branch, I had also cherry picked it into the release branch manually, and at this point I had probably amended or edited the commit message, so the release branch (and now master branch) contain this commit but with a different hash, e.g. dbca321 My adjusted commit message.

这里的问题是，当我从开发人员创建发行版时，它还包含在此阶段不想部署的提交，因此我以master为基础，并排除了我不需要的提交.但是，重新设置基准之后，主服务器，发行服务器和开发服务器之间的上述我的提交消息"的提交哈希是不同的.这可能可以解释为什么每次创建发行版时它都会一直显示.

The problem here is that when I create the release from develop, it also contains commits that I don't want to deploy at this stage, so I rebase against master and exclude the commits I don't want. After rebasing however, the commit hash is different for "My commit message" above between master, the release and develop. This probably explains why it keeps showing up whenever I create a release.

我希望能够使用Git Flow创建来自development的发行版，但是在必要时删除某些提交，而不会发生此问题.通过樱桃采摘手动创建发布分支是实现此目标的一种简便方法，当将其重新合并以进行开发时，它似乎可以很好地工作，但这并不是应该使用Git Flow的方式.

I want to be able to use Git Flow to create releases from develop, but remove certain commits where necessary without having this issue occur. Creating the release branches manually via cherry picking is an easy way to achieve that, and when it is back merged to develop it seems to work nicely, however it's not how Git Flow is supposed to be used.

如何让Git Flow(主/开发)重新回到轨道/同步并实现这一目标?

How do I get Git Flow (master/develop) back on track/in sync and achieve this?

推荐答案

我使用gitflow已有一段时间了.这是我的做法:

I've been using gitflow for a while. Here's my practice for it:

1. 所有内容都会进入develop，直到您觉得准备好开始准备发行版为止.从上次部署开始，这可能是几分钟到几天之间的任何时间范围.
2. 根据develop创建一个release分支，或者更好的做法是-根据应该真正进入发行版的developer分支的最后一次提交.这样做的目的是最大程度地减少develop和release之间的樱桃点或反转，因为它们会引起头痛.
3. 除非您添加/更改了不能进入release分支的内容，否则请继续提交到release.在这种情况下，请提交develop，但再次尝试将其最小化以减少合并的麻烦.
4. 准备好后，将发布分支合并到develop和master中，进行测试和部署.
5. 回到1.

1. Everything goes into develop until you feel you are ready to start preparing the release. This may be any timeframe between minutes and days from the last deployment.
2. Create a release branch off of develop, or better yet - off of the last commit on the develop branch that should really go into the release. The idea is to minimise the cherry-picks or reverts between develop and release, as they cause headaches.
3. Keep committing into release, unless you are adding/changing something that cannot go into the release branch. In this case, commit to develop, but again try to minimise to reduce the merge headache.
4. When ready, merge the release branch into develop and master, test and deploy.
5. Go back to 1.

某些GUI工具可以很好地包装git并提供一键式gitflow操作，但是您应始终努力了解幕后发生的情况，以便在这些自动"工具出现故障时进行故障排除.

Some GUI tools wrap git nicely and offer one-click gitflow actions, but you should always strive to know what happens under the hood to troubleshoot these 'automatic' tools when they fail.

这篇关于Git流-管理主与开发之间的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！