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.
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.
1
|
|
1
|
|
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.
1
|
|
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.
1
|
|
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.
1
|
|
If you would like to omit the arguments then set the default remote
by suppling the -u
argument like this:
1
|
|
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.
1
|
|
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:
1 2 3 |
|
Now you need to open the file in which the conflict occurred.
1 2 3 4 5 6 7 8 9 10 11 12 |
|
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.
1 2 3 4 5 |
|
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!