Getting Started with the Git Version Control System – Part 2

In my last blog article, I demonstrated a few Git basics which were all performed on a local repository. Today I’ll pick up where I left off in that blog article and clone my local MrSQL repository to a file server so others can clone it to their machine from there. Git is a distributed version control system and others could simply clone the repository to their machine directly from mine but placing it on a server will give us a more centralized location that’s backed up and one that will always be available to other users. All changes are still performed against your local copy of the repository and changes are simply pushed or pulled from this designated central location that my team will use.

Cloning a repository to a network location is just like cloning it to another local directory. I’ll specify the bare parameter since I don’t won’t the repository that’s stored on the server to have a working folder:


I’ll add the cloned copy of the repository from the previous example (the one on the server) as a remote named origin to my local MrSQL repository:


Even though I’ve added the repository on the server as a remote, changes still aren’t being tracked between the two. I’ll push my changes (even though there aren’t currently any differences) to the remote and set it as the upstream copy. Notice the differences in the statuses before and after running that command:


Another member of my team who I’ll be collaborating with on this repository can now pull down a clone of it:


When you start out by cloning from a remote, everything is already setup automatically for your local copy of the repository to keep track of differences between it and the remote one. It’s also already setup to know where to push its changes to by default:


Now we can push our changes to this repository and pull one another’s changes from it. I’ll cover those topics in a future blog article.


Leave a Reply

%d bloggers like this: