These are the Git commands I find myself using the most while working on my OPW project, and what they mean. This post is mostly for my reference, so I don’t have to keep looking up the same things in Wikimedia’s Gerrit Tutorial, and in the Git book.

• Update my local master branch

1

git pull origin master

This updates my local master branch so that it’s the same as origin (the remote that it was cloned from). Git pull fetches any new commits from the remote, and merges them into the local master branch. The merge involves ”fast-forwarding,” which means the pointer in my local master branch is moved to the latest fetched commit.

• Create a new branch

1

git co -b MyNewBranchName origin/master

Here co is an alias for checkout, and the command is short for:

1
2

git branch MyNewBranchName --track origin/master
git checkout MyNewBranchName

Git branch MyNewBranchName creates a new branch named ‘MyNewBranchName.’ And –track origin/master sets up a push/pull relationship with the origin/master branch. This means that when I use the push or pull command on my new branch, I’ll be pushing or pulling to the master branch of the remote my repo was cloned from. Finally, git checkout switches me to my new branch.

• Check and commit changes

1

git status

tells me which files I’ve added or modified since the last commit.

1

git diff

shows me how I’ve modified the modified files, and points out trailing/extra whitespace.

1

git add FILENAME

tells Git to commit changes to the file named ‘FILENAME’ in the next commit. And

1

git commit -m 'CommitMessageHere'

makes a commit.

• Synch up with remote

1

git pull --rebase

While I’ve been working on my new branch, others may have pushed changes to the remote. git pull –rebase fetches new commits from the remote, and replays them on my local branch. Here’s how it works:

It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.

• Make a patch

1

git review -R

This pushes changes to Gerrit, the code review tool that Wikimedia uses.

• Alter the patch

  If I want to change the patch I’ve pushed to Gerrit (say, after code review), I can continue working on the branch MyNewBranchName and proceed as above except committing with –amend:

1

git commit --amend

• Delete the branch

  Once my patch has been merged in, I delete the branch, ‘MyNewBranchName,’ that I was working on:

1
2

git co master
git branch -D MyNewBranchName

Some mysteries (for now)

Reminders to look into these things I don’t understand yet:

• How does git review -R work?

• Rather than git pull –rebase above, the Gerrit tutorial tells me to use

1
2

git pull origin master
git rebase master

I’m not sure how this is different, and why I get an error message along the lines of

1

You are about to submit multiple commits. This is expected if you are submitting a commit that is dependent on one or more in-review commits.

when I do this, but not with git pull –rebase.