Last Updated: 08/17/2010 11:44:00 PM

GIT: Working with Remote Repositories

GIT: Working with Remote Repositories

Remotes or Remote Repositories are versions of your project that are hosted on the Internet or network.  Depending on how it is configured you have either read-only or read/write permissions on these remotes. When you are working with a group of developers managing these repositories involves pushing and pulling data to and from these remotes when you need share work. This article will explain how to do that.

We will cover listing remotes, cloning, fetching, pulling, and pushing.

Listing your remotes

We have already worked with remotes in the earlier article The GIT Repository: Attack of the code clones. there we cloned the Framework one project. Since we have the entire history of the FW1 project in our GIT repository, GIT is still aware where it was cloned from.  CD into the fw1 folder and type:

$ git remote -v (-v denotes Verbose: so you will get more info)

Origin is the default name of the branch you clone from the remote. It is a short name you can use, rather than typing the entire URL.  It is also shows that the address for pushing is the same as pulling.  Not that it matters in this case, I only have read access to the the FW1 project.


We already learned how to clone in earlier articles so I am just  going to remind you  the syntax:

$ git clone

GIT it? Got it? Good! Moving on....


Fetching is different from cloning. It only gets the changes from the original remote that you don't have yet. It will get all the branches from remotes, which you can merge into your branch or just inspect at any time. I will cover branches in more detail in the next article. They really are the "killer feature" of GIT, you are going to love it. Anyway here is the command for fetching:

$ git fetch origin (origin in this case is the branch name, yours may differ use the remote -v to determine what should be there)


Pulling is different from cloning, it pulls down the remote and automatically tries to merge it with what ever branch you are currently working on.

Notice how it is stated it was Auto-merging above?  When we pull the origin remote down, it took my changes and any changes that Sean Corfield made and puts them together. Two great tastes that taste great together!


So far you have been cloning, fetching and pulling.  But honestly, dude, don't you feel a bit needy?  At some point you need to contribute and share something.  That is where the push command comes in.  The command format goes like this: git push [remote-name] [branch-name] 

So IF i was allowed to push the FW1 project I would do this:

$ git push origin master

However I am NOT allowed to push to the FW/1 project. Sean hasn't granted me rights to do so (don't blame him.)  Also to be clear, this command works only if you cloned from a server to which you have write access and  if nobody has pushed in the meantime. If you and someone else clone at the same time and they push upstream and then you push upstream, your push will be rejected. You’ll have to pull down their work first and incorporate it into yours before you’ll be allowed to push.

So that covers how to clone, fetch, pull and push these are command that you are going to use every day.   The next major feature, and it is the feature that really sets GIT apart from everything else: Branching.