A few examples of using Git

Russ Bateman
10 June 2011
last update: June 2011

Table of Contents

Merging changes
Previewing changes since pull


This is an addendum to How to Set Up Git.

Merging changes

Eventually, your work will collide with another's. At that point you'll need to

  1. git pull
  2. Clean up the conflicts doing the following as needed:
    1. git merge
    2. git add
    3. git commit
  3. git push

Example

Trivially, I replaced one Git user's key (in gitolite-admin) then tried to push this to the back-end repository which failed because another user had added a project to gitolite.conf then pushed that.

russ@russ-elite-book:~/swan-of-tuonela/gitolite-admin> git push To [email protected]:gitolite-admin ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to '[email protected]:gitolite-admin' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details.

The solution was to git pull the changes, making my own copy up to date, then pushing all back.

russ@russ-elite-book:~/swan-of-tuonela/gitolite-admin> git pull remote: Counting objects: 7, done. remote: Compressing objects: 100% (3/3), done. remote: Total 4 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (4/4), done. From swan-of-tuonela.site:gitolite-admin 69f1df9..12382af master -> origin/master Merge made by recursive. conf/gitolite.conf | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) russ@russ-elite-book:~/swan-of-tuonela/gitolite-admin> git push Counting objects: 10, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 965 bytes, done. Total 6 (delta 1), reused 0 (delta 0) To [email protected]:gitolite-admin 12382af..e5fc3d3 master -> master

Because the contents of gitolite.conf and subdirectory keydirs do not constitute anything difficult to merge, what Git does itself in the git pull (i.e. pull a new copy of gitolite.conf over the top of my existing one) is sufficient and no conflict is present.

In case of actual conflict, however, it would have to be resolved. This is no different than for other source code-control systems. if gitolite.conf had been edited by both of us, perhaps to add new projects, the lines might or might not be difficult to resolve. I would just use vim to merge the file. There are more intelligent tools.

Previewing changes since your last pull

You wish to see what's changed before you actually pull it. git pull is actually a macro operation consisting of

  1. git fetch
  2. git merge

Therefore, if you do the first operation, you can then do...

git log -p HEAD..origin

...to see what happened since the last time you pulled. To merge the changes,

git merge origin

To undo the fetch operation, do...

git reset --hard

... however, all uncommitted changes (including your own) will be lost as well as those you just fetched.