Version control systems come and go. I started with CVS then moved to subversion and now GIT. Apple uses GIT for all of it’s x-code projects but remember that one of the primary rules of a generalists is to stick with what works until you are forced to change. Well the time has come for a change because the project that I am working on is using GIT. So what does it take to become a GIT master?
Some basic useful commands:
git checkout head # return to our main integration branch git pull origin # update our working copy git checkout --track -b <label> master # create a new topic branch
There is no requirement to have a centralized GIT repository but most people do. The first command tells the local system to switch to the local copy of the head of the code stream. The second command tells the local system to pull any changes from the central repository to update the local copy. The last command tells the local system to branch the local copy of the head to a new branch called <label>. Note that you would replace the <label> with a name that you will remember. I tend to use a name that refers to the feature I am working on. These three steps are something that you will want to do every time you start coding a new feature.
Now you start to make changes to code the new feature while the rest of the teams works on their own branches and commits changes for review. If you are fast you may be able to get your changes reviewed before someone else changes the head of the code stream. If not, you will eventually have to merge. Before we move on to describing the steps involved to merge and resolve conflicts, lets consider how we work locally.
git status # show me what has changed
The command above is perhaps the most useful command in GIT. It describes what you have done to your local branch. If you add new files or make changes to files, they will be listed as a result of issuing this command.
git add test.java # add the file to the index git commit # commit the file git push origin HEAD:refs/for/master/topic # submit the patch for review
These commands describe how you work with your local copy of your project. To add a changed file to the patch set you use the add command. Once all the changed files have been added you commit to the local copy of the code with the commit command. The last step of the process is to push your changes back to the remote repository with a push command. The push command can trigger a automatic code review using a system like Gerrit. Gerrit provides a web interface were piers can do code reviews before submitting code for everyone else to add to their projects.
Eventually you will make changes on the same files that other members of your team are changing. When this happens you have to resync your local copy of the head of the code stream.
git checkout master # return to our main branch git pull origin # update your working copy git checkout topic # return to the branch git rebase # rebase the topic to place changes in master ahead of patches committed against the topic
A rebase tries to reapply your changes to the files that have changed by the rest of the design team. If there are no conflicts a rebase automatically synchronizes the files. If your are unfortunate enough to have changed the same lines as someone else on your team then you have to resolve the changes manually. Th rebase is paused, you make the changes and then you tell the rebase to continue.
git rebase --continue # continue after manually resolving conflicts
This should get you started, but you are a long way from being a ninja. Stay tuned for more.