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

I both cases my main 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 pr to master directly.

In the second situation, i am 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.


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.


| improve this answer | |

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.

| improve this answer | |
  • 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 '19 at 10:43
  • 2
    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 '19 at 11:15
  • @Kayaman hmm let me rephrase my question. – Sibi John Jun 18 '19 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 '19 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 '19 at 10:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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