re: why branching on git is wrong VIEW POST

VIEW FULL DISCUSSION
 

I disagree with most of this article, but respect that it works for you.

Any project I've ever worked on where multiple people are commiting to the same generic "development" branch results in lots of merge conflicts unless people are super careful to always pull the latest changes and merge master often. It's also difficult for audit purposes in the future because many features will be added simultaneously on every PR merge.

If anyone decides to try this, I highly recommend that you keep a changelog and follow some sort of commit message guideline.

In my experience, proper use of Git Flow, CI/CD tools, PR status checks, and merge conflict resolution as needed should take care of most of the issues you have with feature branching.

Some useful Git tooling:

 

So my team practices continuous delivery / continuous deployment. The idea here is that we're always pushing to master and deploying to live, leaning on our tests to ensure integration. There are other ways, but it's all essentially 'trunk based development' and is definitely opposed to 'git workflows' á la Gitflow.

We're not large, and we're 'colocated' (management speak for 'sit together') so that might be a factor.

A caveat: I am definitely not an expert at any of this.

Any project I've ever worked on where multiple people are commiting to the same generic "development" branch results in lots of merge conflicts unless people are super careful to always pull the latest changes and merge master often.

You don't need to be 'super' careful. You just need to pull -r from upstream on a very regular basis. I mean, every few minutes. The first point of integration of your code is your machine, the first tests of integration are on your machine. You hit a merge conflict sometimes - it inspires you to pull more often.

It's also difficult for audit purposes in the future because many features will be added simultaneously on every PR merge.

There are no PRs. There are no merges. There are only commits, to master, on your machine, and rebased pulls.

Everything you push will go live on a continuous delivery pipeline. So you cannot be lazy - you must write automated tests to document the features you are implementing.

The key driver here is continuous delivery - no 'releases', no 'big bang deployments'. Just the regular (every 15 minutes usually) integration and deployment of code to live.

I do agree the original author is saying some odd stuff, like:

Now, the scariest part: How to commit half baked features without breaking stuff? or even more, how to commit a new feature that we aren't sure is working correctly?

Just don't deploy broken code. But, conversely, if your code isn't breaking the tests of your other features - then nothing is broken. Feel free to deploy.

A corollary to this: break down your 'features' into small, valuable, deliverable parts. Stop swallowing the elephant whole; use a knife and fork.

Feature flags are a good idea - but only to separate deployment from delivery (i.e. deploy code but prevent its 'delivery' to the user in live). But they should be extremely short lived and probably live in the interface layer. They should not be quite unusual.

Take a look at these just to make sure I'm not mad...

and also

Maybe I should write some of this stuff up in a post if there's interest?

 

Good ol gitflow with pull requests. "Gateflow," if you will. Personally I don't mind it at all and like PRs, however I've worked at orgs that got just as far with manual CRs on a trunk model. It usually boils down to how much you trust your devs, or the dual, are they skilled and reliable enough to not need the merge control hand holding.

 

Not all heros wear capes. Some have the power to merge code. Fully agree

code of conduct - report abuse