git pull fetch merge


In the simplest terms, git pull does a git fetch followed by a git merge.

You can do a git fetch at any time to update your remote-tracking branches under refs/remotes/<remote>/. This operation never changes any of your own local branches under refs/heads, and is safe to do without changing your working copy. I have even heard of people running git fetch periodically in a cron job in the background (although I wouldn’t recommend doing this).

A git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.

Git documentation: git pull


It is important to contrast the design philosophy of git with the philosophy of a more traditional source control tool like svn.

Subversion was designed and built with a client/server model. There is a single repository that is the server, and several clients can fetch code from the server, work on it, then commit it back to the server. The assumption is that the client can always contact the server when it needs to perform an operation.

Git was designed to support a more distributed model with no need for a central repository (though you can certainly use one if you like.) Also git was designed so that the client and the “server” don’t need to be online at the same time. Git was designed so that people on an unreliable link could exchange code via email, even. It is possible to work completely disconnected and burn a CD to exchange code via git.

In order to support this model git maintains a local repository with your code and also an additional local repository that mirrors the state of the remote repository. By keeping a copy of the remote repository locally, git can figure out the changes needed even when the remote repository is not reachable. Later when you need to send the changes to someone else, git can transfer them as a set of changes from a point in time known to the remote repository.

  • git fetch is the command that says “bring my local copy of the remote repository up to date.”
  • git pull says “bring the changes in the remote repository where I keep my own code.”

Normally “git pull” does this by doing a “git fetch” to bring the local copy of the remote repository up to date, and then merging the changes into your own code repository and possibly your working copy.

The take away is to keep in mind that there are often at least three copies of a project on your workstation. One copy is your own repository with your own commit history. The second copy is your working copy where you are editing and building. The third copy is your local “cached” copy of a remote repository.

A good article on Aha! Moments When Learning Git

git command line commit

Git has a “staging area” where files need to be added before being committed, you can read an explanation of it here.

So if you make some change and commit directly, you get some message like:

no changes added to commit (use “git add” and/or “git commit -a”)



Before you add, you could have done a:

git add -u -n

To check which files you modified and are going to be added (dry run: -n option), and then

git add -u

once you added, another way to preview is:

git diff --cached

add modified files

To commit all the change, you can do any of the following:

git add filename1 filename2

or add all changes (from root path of the project)

git add .

or use the shorthand -a while commiting:

git commit -a -m "message".


git commit . -m "save arezzo files"

One other note for SSH

First follow this official link

To use SSH for github to avoid entering username/password, make sure you’re using the SSH one:


And NOT the https or git one:

You can now validate with just the SSH Key instead of the username and password.

If you need to replace https origin with git one:

git remote set-url

git reset SHA

first see the history by:

 git log

. Then use the first 7 chars of the SHA code to do reset.

git SHA b7cg6h3


git branch

use git branch to see what branch current is in, the * means current.

To create a new branch, just use

git branch BRANCH_NAME

Then switch to the branch with

git checkout BRANCH_NAME

To merge, switch back to master and

git merge BRANCH_NAME

To resolve conflict , just modify the master to the desired status and commit.

To delete a branch

git branch -d BRANCH_NAME

Git Rebase

The major benefit of rebasing is that you get a much cleaner project history

more about rebase vs merge .




add google code as a remote in git for intellij

add remote for intellij

I use intellij to create a local git repo.

To add a new remote:

1. create a project in google code.

2. go to this link: Copy the

machine login password xxxxxxxxx 
to the user directory’s .netrc file: ~/.netrc
then change the priv for this file, could be 500/600, i use 600
chmod 600 .netrc
3. go to the project root(where you create the git local repo). use;

git remote add googlecode

this will add google code as your remote.

To verify the remote:

git remote -v

4. now you can go to intellij VSC->git-> push to push change to your remote. Or just use command line: git push googlecode HEAD

About git remote add and push .. master

  1. What is git remote add ...As you probably know, git is a distributed version control system. Most operations are done locally. To communicate with the outside world, git uses what are called remotes. These are repositories other than the one on your local disk which you can push your changes into (so that other people can see them) or pull from (so that you can get others changes). The command git remote add origin a new remote called origin located at Once you do this, in your push commands, you can push to origin instead of typing out the whole URL.
  2. What is git push origin masterThis is a command that says “push the commits in the local branch named master to the remote named origin“. Once this is executed, all the stuff that you last synchronised with origin will be sent to the remote repository and other people will be able to see them there.

Merge local git repo with the openshift one

Openshift has its own git repo for building/deploying app, so we do not want to push twice and maintain 2 local repo for project.

the approach to choose here is to clone your other git repo (ex. on bitbucket) to your local machine:

git clone <bitbucket-repo-url>

Your local clone has then your other repo (bitbucket etc.) as remote repo. Your remote repo is stored with the alias “origin” (the default alias used by git if you clone). You then add the openshift repo as remote to your clone. You do that while explicitly using an alias for the remote repo you add – I’m using “openshift” as alias here:

git remote add openshift -f <openshift-git-repo-url>

With -f option, git fetch <name> is run immediately after the remote information is set up.

To verify the remote:

git remote -v

In order to then be able to push the code from your local git repo to openshift you first have to merge your openshift repo with your local bitbucket clone. You do that by issuing locally:

git merge openshift/master -s recursive -X ours

With this command you tell git to merge the master branch in the openshift git repo with your local git repo. You tell it to merge using the recursive merging strategy and to choose your (“ours”) version when there are conflicts.

Once the merge is executed you’re ready to push your git repo to openshift. You do that by doing:

git push openshift HEAD

You tell git to push your local code to the HEAD branch on the remote repo called “openshift” (the alias we stored the openshift git repo at, some paragraphs further up).

FROM here

Another way is to push to 2 remote from 1 local repo, more detail HERE

git http proxy

Have to use proxy to check out code from github since I am in the company’s network.

The way is:

// Set proxy for git globally
 git config --global http.proxy http://proxy:8080
// To check the proxy settings
git config --get http.proxy
// Just in case you need to you can also revoke the proxy settings
git config --global --unset http.proxy

Git vs SVN

The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.

SVN has the advantage that it’s MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you’re ready to go and can pickup stuff like branching, update etc. later on.

Git has the advantage that it’s MUCH better suited if some developers are not always connected to the master repository. Also, it’s much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).

Git has good performance because operation like diff is done locally.

Subversion is fine.. until you start merging.. or doing anything complicated.. or doing anything Subversion thinks is complicated (like doing queries to find out which branches messed with a particular file, where a change actually comes from, detecting copy&pastes, etc)…

A good article points to the linus video on google talk in 2007