[TBurette]

You didn't just change the source control tool you also fundamentally changed the development process. You used to do continuous integration. Now you are doing feature branching instead.

Feature branching is nice in some cases. For example in open-source project this allows a maintainer to review code (of a potentially unknown developer) before it is accepted. It also prevents a contributor to vanish leaving half-finished features.

I believe feature branching is inferior to continuous integration for most private software development teams. Feature branching along with systematic code review add a lot of friction to the integration of a developer's code into the mainline. The consequence is that developers push less commits that become bigger and integrating each developer's code together become a painful process. This starts a negative feedback loop.

If I were you I would look for the evidences that continuous integration make a team perform better and push to keep git but change the workflow back.

[user5994461]

Don't get it. You're trying to say that pushing to master with no code review is "continuous integration"?

[TBurette]

Continuous integration is when the developers merge their code into a shared master branch at least once a day, ideally several times a day.

A mandatory code review before merging is allowed (that takes some time to be processed) leads to fewer, bigger merges. Imagine waiting for reviews of the 10 pull requests of wrote two days ago, the 10 of yesterday and 5 you created so far today. It's too unwieldy. The latency encourages you to start writing fewer bigger pull requests more spaced out in time.

As an aside, it also tends to reduce trust and cooperation within a team : reviewers become the gatekeepers of the work of contributors. That work is explicitly not trusted until it is checked. Not a great social dynamic I think.

[dllthomas]

> As an aside, it also tends to reduce trust and cooperation within a team : reviewers become the gatekeepers of the work of contributors. That work is explicitly not trusted until it is checked. Not a great social dynamic I think.

This seems to presume a split between reviewers and contributors that hasn't existed explicitly anywhere I've worked, and has only implicitly been a thing in a handful of contexts. Usually, reviewers and contributors (... well, authors - I would call good review a contribution!) are the same set of people.

[kungato]

Holy shit the amount of made up things you just wrote. "Systematic code review adds friction"? At Microsoft we switched from Perforce or whatever the old centralized system was to gitfs and productivity tripled. We didn't have to manage dumb zip files anymore. We already had code review because what is wrong eith you why wouldn't you have it. Why does continuous integration contradict feature branching? How do you have stable versions of the software if you have unfinished features and hacking in the master version?? I guess this makes sense for very small teams early in the development process but then you can just skip feature branching in git for a while. Git is a godsend

[TBurette]

> Why does continuous integration contradict feature branching?

With feature branching, you wait as long needed before the feature is finished. You can only merge when it is fully finished. This goes directly against the continuous integration philosophy of committing early and often.

> How do you have stable versions of the software if you have unfinished features and hacking in the master version?

It requires a strong commitment to ensure that the current state of the code remains healthy (strong unit tests,...). New in-progress features can remain disabled through feature flags, not showing the corresponding UI or not calling the code.

> I guess this makes sense for very small teams early in the development process but then you can just skip feature branching in git for a while.

It's definitely not for every team.

Martin Fowler presents in detail the 'made up things I just wrote' in this article : https://martinfowler.com/articles/branching-patterns.html . See in particular the Continuous Integration section and the following sections.

[kungato]

What is the point of disabled features in master except to not have to have feature branches. Making sure it compiles? You aren't really using those code paths are you? You should have unit tests on your feature branch anyways