Is it possible to mark a git commit as work-in-progress?

Question

I'm aware that there are various opinions and philosophies about whether or not all commits on the master branch should leave the project in a valid, working state. I'm not asking for these opinions.

For the sake of argument, let's assume that somewhere in the master branch history I identified a commit that is actually a work-in-progress commit, i.e. it doesn't build or it breaks other things. Since we are talking about history in the master branch, rebasing or amending (or anything that actually changes the commit) is not an option.

To warn other developers and to make it easy for an automated git bisect script to skip this commit, I want to somehow mark this commit as work-in-progress. How do I do this?

I have thought about using git tag, but since tags must be unique you would end up using tags like wip/<some_unique_id> which is an ugly hack in my opinion. Also, conceptually we do not want to treat this commit as a tagged commit, i.e. we probably never want to check it out, we may not want it to appear in the list of tagged commit points etc.

Answer 1

Use git notes to add notes to certain commits without touching their commit hash.

If you want to annotate HEAD~5 with a note, do

git notes add HEAD~5 -m "better don't use this commit. It breaks the build"

Publish your notes with

git push origin refs/notes/*

Have a read of ProGit for more details.

Answer 2

In other hand, just to bring good practices to the conversation, I would say the described situation where you cannot rebase or amend, being on master, should never happen. Every commit merged on a shared branch (master, develop, whatever) should always be stable. I don't see any reason explaining why a WIP commit could not be on a dedicated branch.

In a preferable approach, you would, for example:

git checkout -b hotfix-branch
git add .
git commit -m "[wip] Fixing index route access"
git push origin wip-branch

Then, after finishing the work:

git commit --amend  # Let's reword to "[hotfix] Fixed index route access"
git push origin hotfix-branch --force
git checkout master
git merge hotfix-branch  # Fast-forward or not, etc., whatever
git push origin master
git push --delete origin hotfix-branch
git branch -d hotfix-branch

In this example (which can surely be improved, that's not the point), amend can be replaced by some fixup/autosquash if needed, but you get the painting. The point is to work on a dedicated branch, use Git to save unstable state through a WIP commit, then rewrite history before merging to shared branch to keep the git log clean.

One should never, as you said, rewrite history on a shared branch. This is why you don't want to put yourself in a situation where such a thing could even come to your mind. Always work on dedicated branches where rewriting history doesn't matter, and merge clean and stable commits on shared branches. (: