1

We use the git flow described here. In this way, we have 3 main branches: develop, master, release, and feature branches.

Develop is development. After development starts and features are deployed to develop, QAs merge to release from develop to test on the QA env.

Then fixes go to release, not develop. Release is the main branch now.

Then master is created from release and is put to preprod. Bugfixes are gone to master now.

Then release is created from master and also merged to develop.

But do we need a release branch? Can we do it without a release branch?

Improve this question
7
  • 1
    What does testing have to be with this branch strategy? I mean, what's the real question? Where to do test? How many branches do you need and why?
    – Laiv
    Jul 22, 2017 at 21:37
  • Question is there, do we need release branch? why not only develop feature and master?
    – vegan
    Jul 22, 2017 at 21:41
  • Once in master and release, do you keep working on features and merging them into develop?
    – Laiv
    Jul 22, 2017 at 21:45
  • 1
    So how could you perform acceptance tests on develop if it's constantly evolving? Develop is not meant to hold a final and complete version of the system. Anyways, you perform tests on all of them. The nature of the changes may vary among branches. Usually QA do tests over "final" and "stable" versions. Those candidate to be released..
    – Laiv
    Jul 22, 2017 at 21:53
  • 2
    This seems more like a software engineering question, not one about actual git usage.
    – code_dredd
    Jul 23, 2017 at 1:26

2 Answers 2

Reset to default
7

If you have one developer you might be able to do it without a release branch. However, you end up with potential downtime while waiting for testing. Git stash makes it easier to switch back and fix bugs. You will need to carefully track which code you are working on.

The failure/usual case when on one branch is:

  • Developer commits work and asks for testing.
  • Some developer commit more work.
  • Testers build and test (not the code that was intended).

Using two or more branches allows testing and bug fixing a release while continuing development of new features. It is common to have one release branch per release.

Another reason to use a separate branch is bugs may require extensive work to to the proper fix, but may have a simple work-around. The work-around gets applied to the release branch. Then the proper fix is done in development. The work around may not get merged back to development.

Improve this answer
2

I completely disagree with the accepted answer.

What you described is actually very desirable. The flaw in the thinking behind the answer is the assumption that the thing being tested is the code on the branch in isolation from other work, but that's not true.

You should be testing fully integrated code whenever you can.

In other words, the idea of "not the code that was intended" is wrong. Let's say that the system is tested and passes all tests. If it passes all tests with the code both that was committed by the first developer and also the code that was committed by the second developer, then that's great. You've just saved an extra test cycle to tell you that the code from both commits is fine.

If the code from the second commit causes the tests to fail, then that's great too. You've just saved an extra test cycle to tell you that the code needs a fix.

If the code from the first commit causes the test to fail, you've learned what you needed to know regardless of the second commit.

If the code from the integration of the first and second commit causes the test to fail, then that's great. You've saved an extra test cycle to tell you that the two developers need to work together to solve the integration problem.

Essentially there is no drawback to testing the second commit as well as the first. I do not understand where in the industry this idea came from from a technical perspective. The only reason I can think of that someone would care is because they want to be able to apportion blame to a particular developer for a failed test. And that sounds pretty dysfunctional to me.

All you're doing with this type of development and branching strategy is making the development process slower and more expensive.

Improve this answer
6
  • Ok, but what if after testing commit A and commit B (with or without problems), there is a new commit C on development? How we can be sure that the product that we want to release has the minimum quality level if C wasn't tested at all? What if that commit C breaks everything? For me creating a new branch a.-helps organizing states of the code/product, b.- avoids add new stuff that can break things and are not needed for the current release. If nobody will add more stuff on development you can just use that branch to test, but in medium-big teams that is very unlikely.
    – mayo
    Jul 23, 2017 at 2:06
  • The answer is that you should have a release branch to which you merge code once it's ready for release. But in that scenario all you ever really need is two branches. Develop and release.
    – RibaldEddie
    Jul 23, 2017 at 2:43
  • Mmmm, I have another question; when you say 'you merge code once it's ready for release'; when is it ready for release? I would say when it's tested/approved by qa. (or with non blocker issues). So, if you wait until qa approves the 'current' code, are developers allowed to push new code? If so, where?
    – mayo
    Jul 25, 2017 at 6:21
  • @mayo it's ready for release when the team says it is. New code should be pushed to the mainline branch when the team is satisfied with it.
    – RibaldEddie
    Jul 27, 2017 at 19:25
  • Don't get me wrong, I like to learn from different perspectives, specially if is about something well stablished as git flow. I full agree with You should be testing fully integrated code whenever you can.. But I'm still having problems to understand your affirmation: there is no drawback to testing the second commit as well as the first on a scenario that each new-code-commit could create another bug that could (in a pessimistic scenario) delay the release date. (With a simplistic assumption that every new-code-commit injects one critical/blocker bug). Thanks for your time, btw!
    – mayo
    Jul 27, 2017 at 20:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.