Working with lots of changes in parallel on git can be painful. You end up juggling branches and commits, and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze.
jj, an alternative to git, gets discussed a lot these days (1, 2, 3, 4) and is often pitched as a solution. While I’m very sold on the problems jj is trying to solve, the way it solves them hasn’t quite hit home with me. Every 3 months, for the last 1.5 years, I try it out for a few days, really trying to make it part of my workflow but eventually I give up and go back to git.
That’s where
git historycomes in.
This was a pretty awesome read. Thanks for sharing.
The last big update to my git workflow was when I discovered --update-refs as it makes maintaining a stack of feature branches much easier. So far I really only have one “main” dev branch and then peel off the sub-branches at they need merging upstream.
However I shall have to investigate how the history commands are exposed in magit. I can see it being useful if you have long held branches that take a while to upstream but are useful to have in your trees.
You might find
topgituseful for maintaining separate interdependent feature branches: https://mackyle.github.io/topgit/topgit.html
https://github.com/mackyle/topgitIt adds some simple commands that manage all of the base and head refs of the branches and automatically propagates merges up the tree when you modify a branch lower down. It has been around for quite a while so it’s fairly stable by now.
Most importantly, it doesn’t do any history rewriting, so you keep the full commit history of your branches while making it easy for other contributors to make commits to the same set of feature branches concurrently.
Oh, nice! Does this do something like Git Butler where you can have multiple branches “checked out” simultaneously, and keep track of which changes belong to which of those branches as you work? But maybe without the commitment that Git Butler requires to using its tooling?
I’ve never used Git Butler, but looking at their site it looks like a whole UI layer on top of git.
Topgit is just a small set of shell scripts that implement the various
tgcommands for managing your patch branches.It’s based around the idea of patch queues, but since it’s using git branches you can have a tree of patch branches instead of just a linear patch queue.
TIL git history.
That said, I’m trying to figure out what the target workflow is, specifically for the “autorebases all your branches to match” functionality. Assuming we are not talking about rewriting published history – and nobody should ever really be doing that anyway, when multiple commiters are using the same branch – I presume this is a situation where the dev has multiple, unpushed features that are WIP, each in their own local branch and building on each other. The trouble I’m having is the number of commits per feature.
If the number of commits per feature is 1, then that means each branch just has one commit that its dependent branch doesn’t have. What is the point of the branch then? Just have a single WIP branch and keep building a linear commit history. If you need to give someone one of the features, then give them the commit which inplemtns that feature and nothing afterwards.
If the number of commits per feature is >1, then this is certainly more difficult to work with, and the appeal of git history starts to shine when dealing with WIP commirs. But why is the dev in this situation, where they’re building multiple dependent features but they’re none are fully complete yet? Because if they were complete, then I presume the dev should squash the commits so the number of commits per completes feature is 1.
My current thought is that having >1 commits to implement a single feature is a transient condition, and good practice is to get to 1 commit per feature. Is there something I’m missing?
I don’t know, the number of times I’ve needed to make two small changes in parallel is certainly non zero. The amount of times I’ve been mostly done with a feature and began a new one before a PR was totally merged is certainly non zero. Even then, some changes can make more sense if broken it into multiple commits (a moot point at most teams since squash and rebase seems to be the norm). You can keep a linear history and still have multiple commits in a branch, just commit (har har) to reading instead of merging.
Regardless, doing commit fixups and rewords are not necessarily rare. These commands are still super useful. Bear in mind that just because something isn’t useful to your workflow, git is used by many different people with many different types of workflows.
Assuming we are not talking about rewriting published history – and nobody should ever really be doing that anyway, when multiple commiters are using the same branch – I presume this is a situation where the dev has multiple, unpushed features that are WIP, each in their own local branch and building on each other.
Yep. There are also situations where rewriting history on branches under review is ok and desired - systems like gerrit work that way. But not github (you can push to an own work-in-progress branch on github, or even push to a branch with a merge request, but the github ui is not designed to review that).
Especially large organizations favour history that is easier to read and mostly linear. This is not needed for a mom and pop web project of a company with three developers.
In respect to the number of commits per feature - one commit per feature can be good. But often changes can be compartmentalized in doing preparatory refactoring, adding the feature, adding tests, and his can be easier to review because the scope of each commit is smaller.
in doing preparatory refactoring, adding the feature, adding tests, and his can be easier to review because the scope of each commit is smaller.
This is the use-case I hadn’t considered. And it makes sense now that I think of it. Though I personally haven’t come across it, since I don’t typically work on multiple, cascaded features at a time. Most of my work as been with waterfall models, so I can understand that other approaches may indeed have cascading features in parallel.
Thanks!
You are welcome!
For me this is a killer feature. For a start, we value atomic commits, where each commit does one small standalone thing. This makes review easier, as well as going back and looking at history to figure out why something was done the way it was. An easy to read history is critical at a large company. Commit messages are often muliline and long and describe the why and why not other alternatives that were considered.
But this also means your PR branch should have clean history, and editing said history is absolutely encouraged (even mandatory). We use azure devops and flawed as it is, the review UI handles this case well. I believe github is far worse at handling force pushes.
Review, design review and even CI runs takes time, so I often need to start building on top of a PR before it is fully finished and merged. Because I work in a sector where we have actual certifications (safety critical systems, think things like brake controllers, medical devices, etc) this means “move fast and break things” just isn’t an option (nor should it be). This also slows down the PR workflow. Even after the C++ code built, you can expect a few hours to run the test suite with full physical simulations. And review can take days for larger and more critical changes.
So yes, many branches have more than one commit. And it is not uncommon to build upon yet to be merged branches (with the knowledge that small things will need to change as the followup is being rebased on top of changes of the original PR).
we value atomic commits
how do you value your atomic commits?
For beginners (which are not the target audience of the above blog post), I recommend Beej’s Guide to git. (But, perhaps learn some jujutsu before - it might make a few core concepts clearer).
