|
I normally have a very casual approach to commits, don’t spend too much time on commit messages, don’t try to fix the revision history, etc. This is okay for a “commercial product”, which has focus on ship or die. But for open source projects, with long software life, where you hope to collaborate with lot of outsiders, where you hope people get the reason of change, where things are more logical as they will not just jump on a zoom call with you, the quality of commits matter. If quality of commits matter, how do we discuss commits? Do we first create the commit and then seek feedback and then revise the commits? It is kind of hard with git. Git makes the commit history permanent and there are a lot of issues if you keep changing the commit using commit amend or rebase. Git kind of fights with you if you try to edit commits after the commits have been made and pushed to remote, after other collaborators have tried out those commits etc. If you modify stuff in your branch before pushing, everything is largely fine. But after collaborators have got the commit and you modify them, conflicts ensue and strong knowledge of git is required to ensure there is no loss of work. It takes a lot of time and care. Only experts should go there, or teams with strict adherence to agreed practices. One option is to “evolve” the commits without git. Create local branch but do not push them, convert the branch to a patch set, a series of files, and share the pitch set via email etc, let people comment on the patch set, and you can modify your local branch and do rebase, rewrite commits, re order etc to your hearts desire. And only once this is done you do the actual commits, probably in one go directly on main branch. This is roughly how Linux works. And git itself. Unfortunately there is no good web based product for this, it relies on email, that too people who can write emails in terminal, can easily automate reading and sending mails via shell scripts, kind of everyone who is at this level of knowledge has such a custom setup that they just can’t share any reusable setup we can just standardise for your company. Git evolve, as described in this article is trying to make this workflow part of git alone, so you can evolve your commits in shared branches, but these branches are not meant to be merged to master. These are special branches, every “logical commit” becomes its own branch, a patch set may contain n commits and for each commit there is now a branch, and each commit in one commits branch keeps track of corresponding parent commit in the parent commit branch. It sounds kind of complex but it’s not too complex if you translate patch set model (any logical change is done using a series of diffs, each diff with a logical name and role). Can’t wait to try it out. |