Git: Stage into Commit, what is the right workflow?

Question

I just created a big piece of code I want to commit in several separate commits.
So I can stage relevant parts, commit, stage, commit, ... and so on until I have all my changes commited.

The missing part is how can I test whether I split the commit correcty.
I.e. whether the part that is in staging area at least compiles?

To do that I must somehow bring my work tree to be in sync with index (staging area) without losing the changes to be committed later.

What is the right way to do it?
What is the quickest way to do it?

Update:
How to do it with magit?

Westphal

Answer 1

You could do it with:

$ git branch task1 # first set of commit to do

An intermediate branch can be useful to record some intermediate commits when you are slowly adding some content to the index.

Then try an interactive session for adding just what you want:

$ git add -i

Add any time you want to check what you have added:

$ git stash --keep-index

If it compiles, git commit your current work, and if task1 is not yet complete, git stash pop to restore the full working tree and repeat.

Once task1 is fully baked, you can trim all those 'task1' commits, and merge the all work in master:

$ git checkout master
$ git merge task1
$ git branch -D task1 # no need for that intermediate branch

If you want to conserve the history of some significant task1 commits, you can rebase first task1 on top of master, before merging master in task1 (fast-forward)

Finally, if your stash still contains some work in progress, repeat the all process for task2.

Myungmyxedema

git stash --keep-index is exactly what I needed. – Rounders

@VonC: Great explanation. This (and `git-rebase -i) is one of the things I really love about using Git and I do this sort of thing all the time. It gives you the ability to craft your commits so that they make sense and contain only relevant (related) changes. – Brittni

git add -p is usually what you need instead of git add -i. – Brightman

Answer 2

Here's a magit way I use:

• make your index for the first commit with magit "u" or "s" to stage or unstage hunk/files/region. (This can be done with git gui also). Once your index is ready to commit:
• commit with "c", write your commit message, Ctrl-C Ctrl-C to commit.
• stash with "z" followed by << Enter>>, this will stash all your change. To get back your changes you can use "A" while your pointer is on the correct stash entry.

make your tests to check if your commit is good. If any change must be done, redo as before, but press Ctrl-C Ctrl-A before commiting while in the screen of the commit message. This will amend (complete) your last commit instead of creating a new one.

Note that if you figure later that some code should come amend a commit that is before the last you've done, you should commit the code on it's own (with a temporary summary), and fold them into the right commit thanks to "L" to access log screen, then point your pointer before both commit you'd like to squish, and press "E" to launch a "git rebase -i" session. Re-order the commits so that the temporary summary is to "fix" the target commit. Quit the buffer, and TADA. All is done.

Beltran