I use git regularly. I'll admit that I use it in a stylized way. The index only seems to add confusion and complication. Is it actually useful? Background: Git has a hierarchy of copies of the object under management: - the working tree. This is the one that you actually edit and use - the index (which lives inside the .git subdirectory of the working tree) - the repository (which also lives inside the .git subdirectory) After this comes a federation of other repositories. These relationships are chosen and configured by whoever manages the local repository. In the simplest non-trivial case, there is a single "upstream" "remote" repository. I'll explain part of my workflow - to show how the index is used - to invite suggestions on improving it In my workflow, the index is almost always identical to the repository. I almost never use "git add" (which affects the index but not the repo). I almost always use "git commit -a" which updates both the index and the repo at the same time. The only time I use the index explicitly is when there is a merge conflict. And that's not by choice: the workflow required to resolve a conflict seems to require the index. Since I don't get a lot of merge conflicts, I don't get a lot of experience dealing with them. Often during development I want to bring my repo up to date with the upstream repo. Here's the procedure I follow: If I have uncommitted changes the the working tree, save them in the stash: git stash If I have local committed changes: # get upstream commits into our repo, index, and working tree: git pull --rebase If this results in merge conflicts: edit each conflicted file to resolve the problem "git add" each such file At this point, the index differs from the repo! "git commit" the resolution If I did not have local uncommitted changes, this will do and cannot result in merge conflicts: git pull If I started out with uncommitted changes (i.e. I stashed them): git stash pop If this results in merge conflicts: edit each conflicted file to resolve the problem "git add" each such file At this point, the index differs from the repo! "git reset" sets the index back to the repo (the conflict resolution remains in the working tree) Done: upstream commits are now in the local repo, the index, and the working tree. If you want to, commit any local changes. If you want to, push local commits upstream.