Git: Everyday Commit Stuff

Russell Bateman
21 March 2012
last update:

I have created this how-to note to reduce every-day stuff to be as simple as it was in Subversion. It's a how-to assuming working in a private branch named jack fronting the master branch. It covers the most frequent, every-day sorts of things. As I see them, they are:

I use a "personal vs. master", two-branch approach in Git. My personal branch is named jack.

The illustration to the right may help visualize what's being done here (click to enlarge). I'm working actively in the (green) local branch. I push what I'm happy with to my remote for safekeeping.

When I want to share what I think is desirable improvements with others, I merge my changes into master, but as they've done the same thing, I first make certain that my local master is up to date with what's made it into remote master and, if anything has been added, merge master into my local workarea whereupon I can merge the new whole into master and finish off by pushing that new whole to master's remote. At that point, Jenkins kicks off a build and deploys my application.

Here's a step-by-step.

Commit fast-forward changes in branch jack to master

This is a bit naïve and only works if there are no other developers working away feverishly. 

1. git status                (tells you what's cooking)
2. git add, rm, etc.         (in consequence of step 1)
3. git commit
    ---loop to step 1 until all is committed---
4. git push origin jack      (pushes all commits to branch jack's remote)
5. git checkout master
6. git merge jack2
7. git push origin master1   (pushes all merged changes to branch master's remote)
8. git checkout jack

Pull changes from master to jack

This always works for jack to get changes from other developers. 

1. git checkout master
2. git pull origin master1   (pulls remote master to local master)
3. git checkout jack
4. git merge master2         (merges changes to master into jack)
5. git push origin jack3

Live cooperation: getting/committing changes from/to master to/from jack

Here, we'll get branch jack ready to receive updates from branch master. Then, instead of merging jack into master, we'll first bring remote master down to the local one (with all the changes from other developers), then merge those changes into jack and, finally, merge jack's changes into master, which will then have all the changes from all the developers including Jack. 

    ---ensure branch jack changes on remote---
1. git status
2. git add, rm, etc.
3. git commit, etc.
4. git push origin jack
5. git checkout master

    ---bring down changes from master remote---
6. git pull origin master1

    ---merge remote master changes into jack---
7. git checkout jack
8. git merge master2         (merges changes to master into jack)

    ---push full state to jack remote---
9. git push origin jack3

    ---merge jack changes changes into local master---
10. git checkout master
11. git merge jack4          (merges changes to jack into master)
12. git push origin master3  (push full state to master's remote)

Unstaging something you mistakening staged 

$ git add subdirectory       # (contains an object file not to be kept by Git)
$ git status
On branch master
Initial commit
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

      new file:   code/code.c
      new file:   code/code.o

$ git rm --cached code/code.o
rm 'code/code.o'

Footnotes

1 If local master is not kept in-step with remote master, conflicts will almost certainly arise that greatly increase the effort required to move code from jack to master or master to jack since it has the potential to add conflict resolution to those points.

2 At this point, there may be conflicts that must be resolved before going on. These could have been minimized or eliminated by respecting the previous footnote. For coping with conflicts, see Simple Merging and Resolving: Resolving differences between branches.

3 Remember: always keep remotes in step with locals, both jack and master unless there is a reason not to do so. In a "personal vs. master," two-branch approach such as this one, there is little reason for local and remote to be out of synchrony since the utility of an intermediate repository is handled by the personal sandbox (jack in this case).

4 Typically, there would not be any conflict at this point unless one's colleague were very, very busy in the time between step 6 and this one.

Last, keeping remote in synchrony with local is effective as a poor man's back-up solution too.