How to make a temporary checkpoint (not a commit)?

Main drawback of committing your changes - whether to a temporary experimental branch or not - is that one loses track of overall extent of work - the combined changes performed up to the checkpoint.

In an IDE, I personally use IntelliJ IDEA, I can see colour blocks in the gutter (near scrollbar) which indicate which lines were edited or added. Deleted blocks of code are indicated by a little clickable triangle, and I can easily see what those deleted lines were by clicking on it.

All this neat IDE stuff works only up to the point you commit your changes.

So, what I would like to suggest is a combination of the above answers - i.e. do commit often and early, potentially edit/rewrite your commit history before pushing/publishing your changes to the remote. Also, after you've committed you perform a soft reset. git reset --soft HEAD^ This way, you will (1) have a commit in your git repo that you can roll back to, if needed. (Use git reflog to get at the hash of the commit, should you later need to revert back to it.) You also (2) get to keep all changes as un-committed so that your IDE can show you the visual indicators of change.

If you make really bad changes you want to quickly abandon, do a hard reset back to your most recent good checkpoint, then a soft reset to the point where you started making your big changes.

Local commit is exactly what you want: a checkpoint you can revert to. Local commits can be amended/squashed/removed before pushing them publicly so you don't need to 'be ready to make a commit'. You have to be ready to make a push (e.g. squash all your local commits into 1 commit before pushing). You can read more about local commit modifications in the ProGit book (I link to Rewriting-History chapter, but suggest that you read all the chapters)

Why do you want to work on the same branch? Make a new branch, say git checkout -b experimental/ni_shrubbery, commit on it, then either merge it back or don't. You can always get back to your master or develop or feature/shrubbery, whatever you're developing on. Branches exist exactly for this scenario. Just don't push that branch out, and all your work is local until you merge into a branch that you do push out.