Suppose the scenario, I modified two source files, but only staging one of them, and execute a commit (local) This particular commit will represent a state of source which nowhere exist in the file system, so I can not test if it is compiles or not. (which is required as commit policy)

Reverting to that particular commit locally (then compile) will result the not staged file(s)'s changes lost. Without pushing it to the remote I can not clone it to an other folder to test if compiles, however pushing it to the remote will make the not verified source available for the team, so make things worst.

The only workflow I can find out is, to create a local (backup) copy of the current sources, then revert the local repo to the commit, (accepting the not committed changes lost (the not staged source file)), compile, if not compiles, then copy back from the backup, modify, take a guess, amend, still not staging what I did not wanted to commit in the first place, then repeat this cycle until the reverted files are compile.

Question

It sounds so overcomplicated, that either

• a) I miss something,
• b) the staging with files requiring strict consistency with each other (source files) the staging is not a usable practice. The modification on multiple files must be atomic (a la ACID).

CodePudding user response：

You can use git stash push -ak to undo all changes to the working directory which haven't been committed or staged yet. Then you can do your testing, commit your staged changes, and then git stash pop to restore your work in progress. The git stash documentation even suggests this usecase ("Testing partial commits" under EXAMPLES).