Require linear history

[christianparpart]

(Prevents merge commits from being pushed to matching branches.)

I would like to enable that @data-man - but I am not sure how much you'd feel comfortable with that.

This would require pull requests to not contain any merge commits, therefore, if you want to update your branch with latest master work, one has to do git rebase origin/master instead of git merge origin/master.

What do you think?

[data-man]

Oh, I'm sorry about this. :(
This is because I was using web-interface of GH.
I'll be careful next time!

[christianparpart]

nah, i know. I also clicked that button already, because it was way to tasty and present, until I realized it's doing a "merge" commit. So my reading is you don't have problems with git rebase then. 👍

[data-man]

I could say that I have problems with git in general. I'm not a very advanced git user. :)

[christianparpart]

i cam help you here. it isnt that hard once the fear has fallen down. let's see how.

[data-man]

I assume you prefer git flow?

[christianparpart]

I had to look up again what git flow is exactly. It's actually simpler, but also, I don't care too much (i.e. i'm not too strict).

So far what I usually do is more like how CVS used to work:

• master branch is containing HEAD development
• work is done in branches and once ready, merged into master
• releases are tagged
• if a release needs a bugfix, that release tag can be used to create a branch off of it.

This works well for small teams for sure. We don't need a second main history line (staging vs production) as we're not multiple teams. Individuals yes, but not too many that it would make sense. So I keep it simple for as long as it works for us. :)