CODEWITHSUNDEEP
git
Dave Ludwig
Dave Ludwig

Reputation: 460

Merging develop branch into master is not what I envisioned

We use a simplified version of Git flow, where most of our work goes directly on develop, and only at release time we merge back into master.

We just made our first release, and as such it was my first time merging develop back into master, since I first created the master branch at the beginning and branched develop off of it.

What I envisioned was a single commit merged back to the master branch, in such a way that if I later checked out master in a clean folder, I'd only see the original commit and the new release commit. Instead, I'm seeing the entire commit history of the develop branch, in my master branch history.

I see why that is. These are just 2 merged branches, after all, and a fast-forward merge would just zip master up to the tip of my develop branch. But it's not what I envisioned. It seems weird to me to check out the master branch and be able to see the entire history of all the work that led up to it from another branch.

I find myself considering, in this case, why we are maintaining both the develop and the master branches if we are just going to merge them together anyway, see the same history, and utilize tags to indicate released commits (we are a small company)?

Is this how most people do it? Is this "correct" (I know that's a loaded question)? Or do people treat master different than all other branches and maybe do a squash merge or a no-ff merge to create a cleaner master branch history?

Upvotes: 0

Views: 287

Answers (1)

Mark Adelsberger
Mark Adelsberger

Reputation: 45659

If you're using a gitflow-inspired workflow, then you probably want to use the --no-ff option when merging.

git checkout master
git merge --no-ff dev

This forces a merge commit even if a fast-forward would otherwise be possible, so you get

--- O ----------- M <--(master)
     \           /
      x -- x -- x <--(dev)

Even so, by default most git commands will still show the detailed history (including the dev commits), but you can override that by using the --first-parent option.

git log --first-parent master

That said, there are other reasons why you might keep the master and dev branches separate, even if you are ultimately going to fast-forward dev into master. One reason is to ensure that master is always the most recent released state. You could do that with version tags instead, but maybe you want a single name that always means "the latest release", and/or maybe you want the most recent release to be what's checked out by default in a new clone, or maybe other things peculiar to your team and project.

Upvotes: 2

Related Questions