[pnathan]

Personally, I don't care about usage of git/hg. That can be dealt with on the job, and is no worse than hiring someone from another shop. As a matter of fact and recommendation, I don't think atomic commits are a great practice to follow in general anyway.

[eldavido]

I agree. I wasn't going to turn this into a general conversation about branching, but since others are going there...

I really dislike gitflow for release-to-web projects. Any form of branching creates integration debt to be paid later. Maybe it's worth it, for instance, when discussing a new feature in its own branch. But gitflow's assumption of a heavyweight "release" process just isn't an accurate reflection of how the best companies work today. For a high-frequency deployment cadence (once/day or more), the level of ceremony required to get a release out is too much. And companies really do have to release that frequently, as high-priority bugs come up, integrations with third-party systems break, etc.

github-flow or the "Continuous Development Flow" as we call it, is much better-suited for high-velocity web development.

I'd be interested to hear what people are using for mobile projects. Maybe gitflow makes sense there, but I don't know that a "hotfix" ever happens, I think people just fix the bug and release a new version to the world?

[pnathan]

So if you're burping out a singular product with a singular release, rolling off master tends to make more sense. The complexity comes in when you're running multiple features and multiple products and multiple teams and having to do long running support of the older products/projects/teams all together.

Simpler is better; but when your actual code path of support looks like a network, that's the complexity you have to eat - I recommend eating it in your branching system (correspondingly, your versioned artifacts get some really funny version identifiers too. :) ).

[eldavido]

I've never encountered this but agree, that can lead to a real hell of branching. Do you dead-end your releases and then backport certain things from your mainline to previous release branches?

Sounds like a headache but probably the best way in certain domains.

[pnathan]

Yeah, each release might be, e.g, firmware version x.y.z.patchlevel, and then you backport fixes and release on patchlevel.

Some customers demand the absolute minimum amount of change - their interface is essentially fixed, all they want is fixes, no more improvements.

Besides firmware, I think this also get applicable when doing larger whitelabel software, each major customer might want to have a particular version they are focused on using.

[shayanjm]

Not here to say that one style is better than another, although I've used gitflow almost exclusively for a few years and it's served well. Pushed features/hotfixes/etc. out the door in a timely manner, and never felt held back by the 'ceremony' necessary to push to prod. CI handles most of that and with the 'git flow' plugin you can easily do a two command deploy while not compromising good branching/repo maintenance practices.

[eldavido]

How big is your team? I work in a company of about 20 developers with approx. 30 repos (lots of small services, "small program methodology") and trying to keep all of this in sync for a single release gets pretty tough.

Right now, there's a lot of ceremony to create release branches on 20+ repos. At the end of our two-week agile sprint, there's always a ton of confusion about "is the release branch open", "should I commit to develop", people opening PRs for review targeting the wrong branch (e.g. trying to merge into release/ but they open feature/ against develop), then accidentally merging release into develop and vice versa...it's just kind of a mess.

Maybe it's just my team that sucks at gitflow? Or our tooling could be better? It just seems like a lot of complexity to manage for a single person who isn't a full-time build/release engineer.

Also, if you don't mind me asking, how frequently do you deploy? We're at once every two weeks but I'm trying hard to move the org toward once/day or more, it's pretty insane how much organizational resistance I have to fight because deployments = "change" = scary.