Git branching strategy for agile project

Question

I have a project that is in the Git Stash Repository. The code will be deployed in four environments (Dev, Test, Stage and Prod). We follow the Agile methodology. Therefore, the development team works for both Release activities and Non Release (Future Release). I have to create branches based on this requirement. Below is my plan.

Three stable branches: master, release and development.

master is the default branch. development will be created from the master. release will be created from development

function branches → they will be created from development. Each developer has one branch of the function, and they combine the code into a forked branch. therefore, deployment of the development environment will come from the development area.

If changes must pass the test environment, we have two ways. one of them combines the development branch with the release branch (deployment of the test environment will come from the release branch). We cannot implement this, since the development branch may have both release changes and without release.

another way is to merge function branches directly into the release branch. so that each developer’s changes can be merged into a release branch. I am not sure if I can implement this method. Can someone please tell me if this way will work? is there an alternative way to deal with this situation.

branching:

main branch ---> expand branch → release branch

branch development --- feature branch1 | feature branch2 | feature branch3

---

deployments:

develop a branch for deployment -> dev

release for → deployment testing

main branch for → staged and production deployments

I cannot merge the development branch into the release branch. With the development of the industry, there are also some changes without release. I only need to undo the changes in the release branches. can branches be merged into a release branch directly? What is the best approach here?

Answer 1

It seems to me that you are very close to choosing Git Flow . In fact, if I'm not mistaken, this is already your base from the strategy that you are describing. It's great.

I heard that your main concern is that you want a non-release “develop” branch, sort of like “just try, don't compile” the environment / branch. Git thread really contributes to the "flow" to production. That is, as soon as something merges with its functional branch into the development branch, it is largely planned for the next (non-emergency) release.

Git's thread suggestion on how to handle this is to not combine the task / function in development until it is probably ready for the next release / release of prod with some fixes. In the Git thread, you will always merge with non-fast forward ( git merge --no-ff FEATURE_BRANCH_NAME ), so that if you are approaching an intermediate release / release and this function cannot be ready, you can collapse (one) merge -commit, thereby removing it from the development or release branch.

I suspect that they are discussing more about this, but just for presentation, I see two possible ways to satisfy your ideas:

1) Have 2 development-branches : one for development, development of the industry, which will soon be tested for intermediate and advanced release after some QA or something else. And one for experimental material that will go to dev / test-environment (for example, through continuous deployment). Let me call it long-term (it's a bad and too long imo name, so do better, or your team will hate you :)).

Thoughts:

• Industry development often needs to be combined into a long-term development branch in order to constantly update it.
• You will probably need 2 development environments for testing, 1 for each branch.
• Danger : branches created from long-term development, which (perhaps by mistake) are combined into development, can drag things not yet ready into the development of the industry. The solution for this may be to: 1) combine the branch of the trait as a short-term in the long term and 2) collect the cherry merge of this command into development. But this is consistency and complexity, and one wrong merger can spoil the entire branch of development, polluting it with things that are not ready for production / production.

2) Create only one branch (as you suggest) and create release branches from the wizard

This is probably the easiest way. It takes a little more effort from each developer, but he is less error prone.

Procedure:

• At the beginning of the cycle, the sprint / development-release release creates the next release branch, coming from the wizard. For instance. release-sprint-42, which when created is equal to the main branch.
• Developers create functional branches with a base from development. They combine the functional branch for development after it is ready for testing, et.c. As you are suggesting now.
• If the function is “correct” and works, the merge transaction created when the feature branch was merged into development is selected using the -m option with the -m option in release-sprint-42, for example. git cherry-pick -m 1 COMMIT_HASH . It is very important to know which parent you choose (in my example, parent 1. Developments should read and understand http://git-scm.com/docs/git-cherry-pick ).

Thoughts:

• The danger may be that a function working in the development branch may not work in the release-sprint-42 branch due to the lack of dependencies. This, thank God, is the reason that we have intermediate environments and internal dates :)
• Cherry picking is not the easiest thing. But definitely the best way to try and avoid dragging unwanted code through merging to the wrong branch.

Round up

This is the best choice for you, depending on how you develop. If you have 2 tracks, for example, "daily support" and "my big feature, scheduled for release this December," you can go to 2 branches. If long-term development is not 1, but a few things and the current thing (i.e. if you usually have a lot of tasks that span several sprints / cycles), I would go for option 2.

Ideally, although by default I would recommend a strategy where the material is split into fairly small pieces and the sprints are large enough that you can usually complete a task / function (i.e. combine and deploy!) For 1 sprint. But from experience, I know that wishful thinking can rarely be realized :)

1 last: I really REALLY really really ask you not to have 1 release branch (perpetual), but create a new release branch for each sprint / cycle, for example release-sprint-42, release-sprint-43, et.c. (regardless of whether you base it on development-branches in an ideal Git stream or on a host branch in the second scenario, I suggested). Having endless branch releases often in my experience leads to lack of material, merging problems, and other bad things. In addition, the master and development must be eternal branches.

Looking forward to this discussion :)