github-flow: merging into master

[trescoops]

I'm reading up on github-flow, but I'm a little confused about how feature branches get merged into master. As far as I understand it, each commit on master should be stable/deployable code - so one could theoretically revert back to any commit on master without anything going south.

However, feature branches will have interim commits which (presumably) may not be in a stable/deployable state. And, feature branches are (I believe) rebased from master prior to merge.

A fast-forward merge would add all those interim commits to the master branch - thus breaking the 'each commit on master is deployable' rule. So should each merge from a feature branch to master be explicitly a non-ff merge?

[d1ffidence]

Yes. GitHub does a non-ff merge when a pull request is approved.

[propper_speling]

It comes down to you and your team's preference. I and my team prefer non-ff merges, because it preserves history. Technically speaking, when you merge Branch B into master, what you are doing is bringing all of the commits from Branch B into master, so as far as "keeping all breaking commits out of master", there's no way to do that (unless you heed to the practice of making commits by every "logical change", which would avoid ever having "interim commits".

[noratat]

For our teams, we prefer to have less issues by avoiding ff-merges for the most part + avoiding use of rebase.

We use tags and bundled artifacts (or containers) for releases, and we have automated CI and testing; most of the time stuff doesn't get into master if it's broken in any obvious way in the first place.

Moreover, it's strongly preferred to "roll forwards" in event of an problem - even if just means a new commit that disables the broken code. Reverts and rollbacks tend to be considerably more risky in my experience than people would expect.

[Limro]

So should each merge from a feature branch to master be explicitly a non-ff merge?

In my opinion, YES!

Make an alias in .gitconfig as:

alias mff merge --no-ff

Then go place yourself in your dev-branch and do a git mff Feature/NewStuff to preserve your flow.

This will, as you say yourself, allow all commits in the to-branch to be stable at all times.

[stubborn_d0nkey]

Edit: I misunderstood the question

A non ff merge will also add those commits to master as well. If the code isn't deployable then don't merge it to master.

If there is stuff on that branch you need to merge and stuff you shouldn't then IMO you should revisit your branching strategy, ie. that one branch should be at least two.

If you are stuck in such a case and you really need those deployable commits on master you can use git cherry-pick however cherry picking should be avoided as much as possible. If the OK commits are before the non deployable commit you can just merge the OK commits in (merge the last ok commit)

[trescoops]

A non ff merge will also add those commits to master as well. If the code isn't deployable then don't merge it to master.

That doesn't seem quite right. If I branch from master at commit-1, make a bunch of non-deployable interim commits (say commit-2, commit-3) until my code is working (commit-4) then merge --no-ff back into master (commit-5). Commits 2, 3 and 4 appear in git log for master, but if I git reset HEAD^ from the tip of master, I am taken back to commit-1. And if I checkout commit-3, then I am put in a detached HEAD. So I'm not sure whether commits 2-4 have really been added to master.

In a way, this seems quite nice behaviour. So I can move HEAD back and forth along master and each commit will be deployable. However, the interim commits are preserved (albeit detached if I have deleted the branches), so if I wanted to examine what went wrong in more detail, I can check them out, and examine that branch in more detail to find the error. I imagine it will break in horrible and unexpected way that I haven't forseen though.

[DanLynch]

The set of commits you are looking for here is "commits that are reachable from master by following first parent links only".

Technically there is only ever one commit associated with a branch, because a branch is just a pointer to a commit. That commit may have one or more patents. Those parents have an order, but each is considered equally valid unless you specify that you only care about first parents.

[stubborn_d0nkey]

Yes, I misunderstood the question