0

When creating a new feature branch should I baseline from master branch or dev branch and why? I'm used to creating a branch from master as the baseline, making my changes and merging it back into dev but recently at my new organization it was suggested that I create the branch with dev as reference.

I both cases my primary branch was master. In the first situation, I would branch from master, do my changes, merge to dev, test it and once all this was done I would raise a PullRequest (PR) to main directly.

In the second situation, I'm supposed to branch from dev, do my changes and raise a PR to dev. If and when its approved its picked up for release and merged back into master during the release.

4
  • 2
    Master branch is the master Jun 17, 2019 at 9:52
  • 2
    as a rule of thumb: merge from that branch into which you want to merge later. This minimizes the chance of merge conflicts.
    – amon
    Jun 17, 2019 at 10:58
  • 1
    Related: softwareengineering.stackexchange.com/q/131171/53019
    – user53019
    Jun 18, 2019 at 12:22
  • I've reverted the master -> main change here purely because everything else around this (the title, the comments and all answers) still refer to master and it's very confusing to read with a mix of terminology. For avoidance of doubt, I'm fully in favour of main for any new questions etc. Mar 6, 2023 at 11:32

2 Answers 2

3

Generally speaking if you have a master branch and a development branch, and you're following some process (instead of randomly doing things in git), you are most likely expected to branch from dev instead of master.

This is because master (or trunk or main or whatever it's named) should represent a very stable state of code, ideally the same as the last release. On the other hand if you don't release often, and are working with multiple developers, the development branch could contain a lot of changes and be very different from master. Since you (hopefully) won't merge directly to master, you could end up developing on top of "stale" code (from master) and when merging to development you would notice that "oh no, I've written code that doesn't fit well with the code in development".

Since development will most likely be merged back to master to represent the new "release state", branching off of development allows you to develop on top of more up-to-date code than if you were to branch off of master. This means you'll have less merge conflicts.

There are different factors that affect how much of a difference this makes (e.g. if you have a daily build/release cycle, your master and development will never be very far from each other), but this is one logical reason (and not just a convention) why development should be used instead of master for branch root.


What I've described is your second situation, which follows gitflow at least in principle. Your first situation describes a different branching model. Git doesn't mandate that you do things in a specific way, but time has taught effective processes to use.

In your first situation you have to make sure that dev and master are synchronized, so you don't test code in dev that would then break in master. This may not be an issue, and it may be completely intentional if short release cycles are to be used. It may also mean that development can be "broken", if the idea is that features are pushed to dev and automated testing is done on that branch when new code is pushed. Ideally you wouldn't risk pushing broken code to dev, running tests locally before pushing, but if for example the test set is heavy, it might not be possible.

TL;DR a suitable branching model depends on a whole lot of things, such as the length of the release cycle, the amount of testing done, the amount of developers and of course the nature of the system. There are conventions and processes that are developed to minimize the complexity of multiple developers working on the same codebase, but there are no strict rules except for one.

"DON'T BREAK MASTER!".

4
  • In open source projects you often have contributors which are not familiar with that concept. And you can not expect they read your CONTRIBUTE.md file. You can be happy to even have a contributor. So how do I setup a project that way that feature/bugfix branches are based on dev instead of main.
    – buhtz
    Mar 4, 2023 at 15:50
  • I don't believe ""DON'T BREAK MASTER!". is always such a strict rule. If you have robust quality checks (whether automated or manual) between master and production then having master briefly broken is not a disaster. Fowler's CI certification cartoon doesn't say master must never be broken, it says it should be fixed within 10 minutes if it is broken.
    – bdsl
    Mar 6, 2023 at 11:23
  • If it is allowed to be broken for ten minutes then it isn’t “master”. Master should from time to time be replaced with a version of the development branch that survived production for some time.
    – gnasher729
    Mar 6, 2023 at 12:51
  • @gnasher729 It's definitely not a universal rule of git usage that there is a development branch and a master branch. You can see the CI certification cartoon here: martinfowler.com/bliki/ContinuousIntegrationCertification.html
    – bdsl
    Mar 6, 2023 at 13:19
5

Ultimately it's up to your organization how they choose to organize their branches.

From Git's point of view, the name master is just a convention. It doesn't matter. Instead of master, your main branch could be dev or baseline or purple-elephants. It makes no difference to how Git works.

So if your organization says to branch off dev, then do that.

9
  • 1
    It's not necessarily just a convention. If you're using gitflow, master and development have strict rules (well conventions, but if you break them why use gitflow at all) about where to branch from / merge to. Of course if you're not following a particular branching model, then you can do whatever you want. This doesn't really answer the "why" of the question. Also note how he said he's used to branching from master and merging to dev.
    – Kayaman
    Jun 17, 2019 at 10:43
  • 3
    No, it really is just a convention. You can name your Git branches any way you want to. Gitflow has its own conventions, and again, they're just conventions. Anyway we have no way of knowing what rules his organization is following that require the conventions they use.
    – Kyralessa
    Jun 17, 2019 at 11:15
  • @Kayaman hmm let me rephrase my question.
    – Sibi John
    Jun 18, 2019 at 7:21
  • Since the names of the branches are irrelevant, would you say that switching the names master and development with each other would be perfectly acceptable?
    – Kayaman
    Jun 19, 2019 at 10:16
  • "Irrelevant" is a term no one used here. Better to say that the names have meaning within context, and one development team's context will differ from another's, so they will choose names that have relevance to themselves.
    – Kyralessa
    Jun 19, 2019 at 10:36

Your Answer

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

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