Merging in Git, how do you prefer doing it?

Share unrelated electronics stuff, ideas, rants, etc!
Post Reply

Which do you prefer for merging?

A squashed merge.
2
67%
A fast-forward merge whenever possible.
0
No votes
A normal merge.
1
33%
 
Total votes: 3

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Merging in Git, how do you prefer doing it?

Post by Jubatian » Fri Aug 17, 2018 10:28 am

So I was doing a small merge (thanks Artcfox, collecting the RLE mode patch for CUzebox), and once again I faced the problem of how I should be merging it.

There are three options usually:
  • Fast-forward merge: This is only available if the branch is a clean descendant of the master. The result is that the master (or whatever other branch) receives all the commits like if they happened there. Networking is clear (from where the commits came).
  • Normal merge: The history that it was a branch is preserved, the master's timeline jumps to the merge commit. Networking is clear (from where the commits came).
  • Squashed merge: The whole branch is squashed into a single commit, and that commit is added to the master. Networking information is lost.
For some reason squashed merges seem to be preferred, but I don't really like that the cost is losing the history of the branch. On GitHub it feels even worse to me as it has tools to view the history, and sometimes it is interesting to see who contributed what, how the project evolved.

What do you think about this?

User avatar
L4rry
Posts: 239
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Merging in Git, how do you prefer doing it?

Post by L4rry » Fri Aug 17, 2018 12:21 pm

Yeah it's an interesting topic. From work experience, everybody has a different take on it. I personally prefer a squash merge, because it's trivial to revert if you should choose to do so and you get the entire scope of a merge by comparing a single commit hash. Also, the history is preserved on the branch it was merged from unless you chose to delete it (I never quite understood why people insist on deleting branches after a merge. Seems unnecessary to me)

But your points are valid too. If your master branch has a low frequency of changes, then something like a squash merge becomes less important as it does for a project that gets daily merges to master from various branches. Everybody has there own way of committing to their development branches. I might commit things just because it's the end of the day and I don't like to leave a dirty working directory. The commit in itself might be meaningless and just clutters history.

User avatar
Artcfox
Posts: 944
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Merging in Git, how do you prefer doing it?

Post by Artcfox » Fri Aug 17, 2018 11:11 pm

I've gotten comfortable with: Create a feature branch named the same as the issue in JIRA, push to upstream, submit PR, merge it using GitHub, delete upstream branch. It keeps the history of the branch, shows merges, and you still have the local branches on your dev boxes. And as long as you mention the ticket number in the commit message, JIRA links directly to GitHub so you can quickly see all the code changes that went into solving that ticket.

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Merging in Git, how do you prefer doing it?

Post by uze6666 » Fri Aug 17, 2018 11:56 pm

I tend to prefer sqashed merge but normal merge is good for me too. I mean, the Uzebox is not an enterprise projet so whatever works and makes you happy. :)

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Merging in Git, how do you prefer doing it?

Post by Jubatian » Sun Aug 19, 2018 6:54 am

So I guess that's squashed merges for the Uzebox master then!

After experiencing what each does, how it affects the history and network, I pretty much lean towards preferring normal merges. Keeps the master's timeline clean of clutter, while the network is preserved, I just like the looks of it, it is more informative on how the project evolves. An example could be a video mode assuming you kept its topic branch active after the first merge into master, and continued development on the topic branch: When doing squash merges, the networking info indicating when the video mode was first added to master, and when its further revisions were merged into master would be lost, a tool wouldn't be able to follow it. At least it seems like so for me at the moment.

Artcfox: Guess then JIRA gets around this through its issue tracker? (I imagine that the squash merge commit having the link to the issue would connect with the merged branch solving the issue) I didn't see that system in action so far.

User avatar
Artcfox
Posts: 944
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Merging in Git, how do you prefer doing it?

Post by Artcfox » Wed Aug 22, 2018 12:32 pm

Jubatian wrote:
Sun Aug 19, 2018 6:54 am
Artcfox: Guess then JIRA gets around this through its issue tracker? (I imagine that the squash merge commit having the link to the issue would connect with the merged branch solving the issue) I didn't see that system in action so far.
I haven't tried it, since we don't use squashed merges. If a developer wants to squash all the commits on their feature branch before they submit a PR into master then they can, but the merge into master shows up as a merge commit. A reviewer might request further code changes, in which case the developer would make the changes, commit, then push to that feature branch up on origin and the code review would automatically show the updated code for the reviewers to continue reviewing. Per policy, I don't think anyone is allowed to work directly on master.

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Merging in Git, how do you prefer doing it?

Post by Jubatian » Wed Aug 22, 2018 4:59 pm

Artcfox wrote:
Wed Aug 22, 2018 12:32 pm
Per policy, I don't think anyone is allowed to work directly on master.
That's a fine standard model for a Git workflow: You have an integrator who is responsible for maintaining the master. (On Git's relevant documentation this is the second figure, guess you have this then) He ensures that only code which went through the appropriate verification enters the official central repo.

Otherwise it seems you (the integrator) are doing normal merges, while developers working on a feature branch might tidy their branch up before offering it for pull.

User avatar
Artcfox
Posts: 944
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Merging in Git, how do you prefer doing it?

Post by Artcfox » Wed Aug 22, 2018 5:29 pm

Well the integrator is usually whoever submitted the PR. Once the code has been approved, either the person approving it, or the person whose code it is clicks the merge button to bring it into master. Either way it gets reviewed first.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest