Previous Section – Merging

Remotes

Now you understand how branching works in git you will be able to create your own feature branches, do some work in them and merge them. But how do you share your work with other people? With svn this would normally be done by committing your changes directly into the central repo. You select the files that you want to add to the changeset and then provide a commit message. Svn then calculates the diffs for the files you specified, sends them to the central svn server and a changeset is logged against your name. That’s it. The changes are there for all to see. As you might be expecting by now, things are very different in git! They’re a lot more complicated too unfortunately

The first thing to bear in mind is what we started off talking about; git is distributed. There is no central repository, so it would make little sense if you couldn’t interact with the repo or add to it without the presence of a central server. Because your local repo is a full clone of another repo you actually have all the data for every commit, every commit message, every file, ever, without even connecting to a server. It’s all there on your hard drive already. Similarly you can commit directly into your local repo. So when you actually create a commit it is only being committed to your local repo, it doesnt go anywhere else. This allows you to work on your feature and commit it incrementally without anyone being able to see what you are doing. This is great for keeping experimental code around so you can refer to it later, but what about when you do want people to see your work? Perhaps when your feature is complete? Well that is where the git push command comes in.

So what is git push? Well first we need to know a bit about how git tracks ‘other’ repos. Let’s say you cloned the framework repo from github. Git will remember where you cloned the repo from so you can utilise the info later on to push changes back out. But because git is distributed you could have cloned the repo from anywhere, from anyone. For arguments sake lets say you cloned the framework repo from my laptop onto your work PC, then you did some work on it and wanted to push the changes to the repo on you PC at home so you could continue while you are working from home. There are 3 repos involved here and git tracks all of them as ‘remotes’. A remote is essentially just a label to refer to another copy of the repo (potentially) on another machine. From the point of view of your work PC there are two ‘remotes’:

Git can operate over several different protocols including a specific git-protocol, but most often it is run over SSH. This means it is relatively easy to establish connectivity to other repos. Also because git is running over ssh you can use ssh keys to authenticate other users which is very secure.

You could have many different ‘remotes’ defined in git, one per team member perhaps, so you could push changes to anyone that was interested. Similarly people could pull changes from your repo too.

In practice many people operate a hybrid approach where there is still a central server that is designated as the definitive repo but still operate in a distributed fashion. For the Linux kernel this designated central repo is probably Linus Torvalds’ netbook, whereas for Orange Digital it is GitHub.

Git operates another convention whereby the ‘remote’ that you cloned the repo from is automatically called ‘origin’. You could call it anything you like but by default it is called origin. This makes it quite easy to push and pull changes to/from github using the remote ‘origin’.

Pushing

So you know all about remotes, can you push changes yet? Well, yes of course! As ever with git the syntax for this is very simple but the stuff going on under the hood is quite complex. Say you created a branch called feature1 and want to push the changes to github so it can be seen by your whole team. This is the command you need:

git push -u origin feature1

This instructs git to take branch ‘feature1’ and push it to the remote called ‘origin’, which assuming you cloned from GitHub, will still represent GitHub. The -u is related to tracking changes which we’ll come onto later.

Assuming everything went well you should see your changes up on GitHub and people should be able to update their own repos to be able to see your new branch.

Next section – Tracking Branches