Code Crafting Blueprints

Code Crafting Blueprints

Hard-earned webdev knowledge at your fingertips

Collaboration Made Easy With Git

| Comments

In the previous two Git articles we’ve only talked about local repositories which are great for going back to previous changes and to keep track of your code. What it doesn’t do is to let you collaborate with other developers. It also doesn’t help much if your hard drive crashes. This article explains the basics on using remote repositories.

Git logo

This is the last of a three part article serie about Git. Read part one here and part two here.

To be able share a repository you’ll need to set up it up on a server that everyone has access to or, as an alternative, use a hosted service like Github.

Setup

Every remote Git repository uses an url as identifier and you either need to clone the repository from that url or add it as a remote. The only difference between a cloned repository is that a remote named origin is already added.

Clone a remote repository
1
git clone <url>
Add a remote repository to an existing repository
1
git remote add <name> <url>

Unlike many other source controls you are not limited to only one remote with Git. You can in fact add as many as you want. To list all your remotes use the remote show command.

List all remotes
1
git remote show

If you cloned the repository it already has a remote called origin. If that’s not the case you can easily add it with the remote add origin command.

Add a remote repository to an existing repository
1
git remote add origin <url>

Pushing and Pulling

Now you can continue to work just as before and every time you complete a feature you just push the changes to the remote repository using the push command.

Pushing to a remote repository
1
git push <remote> <branch>

If you would like to omit the arguments then set the default remote by suppling the -u argument like this:

Set the default remote while pushing
1
git push -u origin master

But what about the code your team members produce? Whenever another team member has pushed to the repository you can pull their changes into your local repository with the pull command.

Pull from a remote repository
1
git pull

It’s a good practice to always pull before you start making changes to the code. This makes it less likely that your changes will collide with the changes of your team members. But if conflicts occurs anyway, and you can be sure it does, Git provides excellent tools to help you resolve them.

Solve Merge Conflicts

If both you and another developer has edited the same file, a merge conflict could occur. Git does a great job of automatically merge changes but if you both has edited the same function or the same line there is no way for Git to know which change to keep. This is when a merge conflict occurs and you manually need to select which version to keep.

Git shows you a message like this when a merge conflict occurs:

Output of git push/pull when your version is not up to date
1
2
3
Auto-merging list.txt
CONFLICT (content): Merge conflict in list.txt
Automatic merge failed; fix conflicts and then commit the result.

Now you need to open the file in which the conflict occurred.

File with a merge conflict
1
2
3
4
5
6
7
8
9
10
11
12
<<<<<<< HEAD
* ruby
* Objective C
* python
* c#
=======
* Objective C
* c#
* ruby
* python
>>>>>>> master
* scala

In this case the content between <<<<<<< HEAD and ======= is the last commited version of the file in the remote repository and the content between ======= and >>>>>>> master is your local version.

As you can see your team member has changed the order of all the languages in the file. Hopefully there’s a good reason for this. If your team member has been a good team player there should be a nice descriptive message added to that commit. You can see what it says using the git log list.txt command.

Output of git log
1
2
3
4
5
commit 2b4cc2375e17fad29ee5899dda8a0832036f276f
Author: Gabriel Svennerberg <[email protected]>
Date:   Sun Jun 17 15:34:58 2012 +0200

    Changes to order of languages to match the new specifications.

Ok I guess it looks like this is a valid change. Just remove everything between <<<<<<< HEAD and ======= and the >>>>>>> master line and you’re good to go.

Great, the merge conflict is solved. Just add this change, commit it and push. Here’s a good time to once again point out that a good, descriptive commit message is really important.

Conclusion

Git makes is easy to collaborate and keep track of changes to the code base. Remote repositories are also the key to backup your code to a secure place.

Using a solid source control system like Git is crucial for collaborating with others and keeping the code base safe. Hopefully this small series on Git has given you the confidence to use it in your own projects. So if you don’t already have it up and running, now is a perfect time to start!

Comments