Stage, commit, push (Git)
The complete procedure from changing a file locally, up to having it appear (in our case) on a server, seems to be like:
- Modify files in your workspace
- Staging: Add them to the staging area or index -
- Commit them to the local repository -
git commit, think git safe
- 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 .
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
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 -ahere
- Through clients - See the discussion here, where someone noticed that the Turtoise SVN client appearantly does so