Stage, commit, push (Git)

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen

The complete procedure from changing a file locally, up to having it appear (in our case) on a server, seems to be like:

  1. Modify files in your workspace
  2. Staging: Add them to the staging area or index - git add
  3. Commit them to the local repository - git commit, think git safe
  4. Push them to the remote repository - git push, think git upload

Why so many steps?

The basic reason for having multiple steps, is because you have multiple choices at each step - To have finer control over exactly how you want to approach version control [1].

For me, it seems overkill to have this number of steps, but that's likely not the case for everybody:

  • Having staging and committing separated, allows you to commit only parts of a file. But seeing the discussion here, it seems a bit far-fetched. SVN for example seems to also have these steps separated, but in practice always does it as one step. It also appears that you can skip staging in Git as a separate step through committing with the flag -a (all): git commit -a
  • Maybe you don't push always to the same repository
  • Maybe having these separate steps, aids in conflict resolution
  • When you commit multiple files, do you want to add multiple comments, or only one?

If so desired, steps can be combined. E.g.:

  • Combine commands in bash scripts
  • Through Git commands themselves - See example git commit -a here
  • Through clients - See the discussion here, where someone noticed that the Turtoise SVN client appearantly does so
  • ?

See also