Step-by-Step: Programming Incrementally | Hacker News Reader

Step-by-Step: Programming Incrementally

ourmachinery.com

75 pointspmarin12 comments

At my previous job we were mostly working like this and I still think it is the better way. I would sometimes create 10 commits or so a day, all of them very small. This way everybody gets the latest code much earlier.

Feature branches discourage refactoring because if the work that is off master is bigger merge conflicts can easily get much hairier

Small commits also forces one to have a good automated tests because one is not going to test everything manually after every very small commit. It ties in very nicely with the TDD cycle.

Not all work can be done this way so sometimes one needs a feature branch but most of the time it is not needed. In many cases feature switches are a good alternative, if needed.

Some interesting arguments are presented in this article but there are a couple of pretty important issues this workflow totally elides. First of all, where are code reviews? If you're committing directly to master, does that mean every commit has to get reviewed before it can be merged? So in fact you are creating a new branch for every commit and then merging it into master (presumably amending to address review comments). So now you are back at square one. Secondly, how do people work concurrently without constantly pulling/merging? I suppose you could argue it's better to resolve small conflicts frequently than to address them all at once, but surely there are times when a developer needs to be able to work unfettered.

Overall I like the idea of working incrementally and ensuring that every commit adds value. I'm just not sure about the specific git workflow presented here.

Normally the idea is presented as "short-lived branches", with short meaning "as short as possible" e.g. days instead of weeks. At that point it's non-controversial and the argument about peer-review vs. no-peer-review can be separated from "how do i get this back into the mainline without breaking everything?"

Also I merge master into my branch several times a day just as a matter of habit, because yeah it's usually better to discover conflicts ASAP instead of two weeks after they've happened. Keeping your branch short-lived also helps prevent conflicts in the first place.

Seeing as the advice is given to work in feature branches, I think the target audience is those who just started working with git? Or on a bigger project, with other people?

The only time I'd maybe work without feature branches is on a solo project that hasn't been launched yet. But even then, probably for a quick prototype. As soon as there's a publicly deployed master, it's feature branches each and every time. Too much can go wrong ;-)

I led a team of 20 devs using this approach. It worked very well. No one stepped on each other's toes. The advantages noted in the article are so true. Avoiding feature branches was a game changer for us. Move faster with much less stress.

The important problems to solve are all social: how do you divide the work, how people talk to each other when working on the same code, etc. If you solve those right, your team can be successful with any git workflow, and if you solve those wrong, they will fail despite any git workflow.

After you get the important things right, the will exist relevant optimizations on the workflow like those on the article. But they won't make or break your team, and will certainly depend on a lot of details so any universal preaching must be taken with care.

Smaller code reviews more often.

You can still do a code review using an incremental workflow. Do a pull request and wait someone for review and merge. The idea is to do them often on small incremental changes. It is much faster to review a small code change.

Pairing is the solution to this. I worked for four years doing trunk-based development, and pair programming is basically live code reviews.

where are code reviews

A valid answer might be "nowhere". Code review is a hot topic at the moment, but I'm pretty sure a lot of software I've found useful over the years was created with little or no formal review, and I think we should at least consider the possibility of leaving trustworthy developers to work without constant oversight.

Sounds like Agile done right to me: release often incrementally and make sure each release is a working version, then iterate.

My previous job does the opposite. We create a branch on for a release, then everyone works on main. Whenever a feature is done, we merge to the release branch, run tests on it and release the software. Worked very well for a long time. I guess it makes agile more difficult?

I've always found that the longer a feature branch is worked on separately from master, the merge back into master is that much more painful.

Reply on news.ycombinator.com