When writing source code for a computer application, we need a place to save source code. A single software developer can save source code on his own computer and perhaps back it up regularly. This solution, however, does not scale when multiple developers are involved. Source control tools assist in collaborative software development by allowing multiple developers to work on source code concurrently.
Software developers can choose among several source control tools. Open source control tools include CVS, SVN, and git. Many commercial options are also available. CVS is the original source control tool for many years. SVN improved upon features in CVS. Git is a new source control tool that has more features than either CVS and SVN. Both CVS and SVN commit each file individually whereas git can commit multiple files in a single entry. Git also has several popular cloud-based repositories on the web, for instance, github.com, bitbucket.org, and unfuddle. A repository is a master copy of the source code.
Git
Git requires a specific workflow for collaborative software development. A git repository, where source code is saved, can exist only on a person’s computer or hosted on the cloud. When working with the cloud, a developer first creates a new repository on one of the listed websites. After creating the new repository, a developer is granted access to the repository with a special URL. Here’s an example from a recent project of ours:
git@github.com:yetihq/AFNetworking-TastyPie.gitGranting Access to a Git Repository
This special URL uniquely identifies a repository, but it does not grant access to the repository. A developer gets access to the repository by creating or reusing a private SSH key on his computer. Let’s see how this can be done in Linux or Mac.
- Open a new terminal
- Type in the command at the prompt:
ssh-keygen -b 4096 - The user is prompted to save the key; we can use the defaults.
- The user is prompted to add a password. This password is used to lock the key file locally; it can be different than the website.
Once the ssh key is created, the public portion of the key should be uploaded to the repository website. If the developer kept the default settings in the previous step, then the public key file is ~/.ssh/id_rsa.pub. The file’s contents are opened in any text editor and copied onto the website in it specified location. For github.com, the public key is pasted in Account Settings > SSH Keys.
NOTE: The public-private key pair should be kept secure and not shared to anyone else.
Accessing a Git Repository
Now that a developer has created a git repository on a website or wants to access an existing repository, the developer has two ways to check out (create a local copy of) the repository. Both approaches require an open terminal:
Option A
1 |
git clone git@github.com:yetihq/AFNetworking-TastyPie.git
|
Option B
1
2
3
4
5
|
mkdir AFNetworking-TastyPie
cd AFNetworking-TastyPie
git init
git remote add origin <span style="color: #444444;">git@github.com:yetihq/AFNetworking-TastyPie.git
git pull origin master</span>
|
Making a Commit
Now a developer modifies source code as usual. When a developer is ready to submit changes back to the master repository, a developer has to grab the latest copy of the repository, merge local changes into the latest copy, and then push the changes to the master copy.
An easy way to make commits on a Mac is to use Tower and Git Cola on Linux. The steps are the same for each.
The workflow:
- git stash
- git pull origin master
- git stash pop
These steps are necessary when working with a repository with multiple contributors. Tower will perform these steps automatically for you.
NOTE: You can skip stash and pop if you are the only person working with a repository.
Git does not merge conflicts for you. When you pop the stash, you will have to search for <<<<< and >>>> in a text editor to resolve conflicts. Tower will guide you through the process of resolving conflicts.
Once you have finished merging your source code with the remote copy:
- git add .
- git commit -m “some message describing the changes made”
- git push origin master
To choose which files to add, a developer can preview changed files using:
1 |
git status
|
For each modified file, type in:
1 |
git add <filename>
|
Reviewing Changes in Git
To review the change log in git, the following commands are handy:
1
2
|
git status
git log
|
Again, I prefer using GUI tools for these tasks as it makes reviewing much easier.
Not All Files are Useful
Ideally, the files and directories for source code should only be created by developers. It is unfortunate that almost all source code editors and development environments add machine-generated temporary directories, files, and binaries. To solve this problem, the base directory for a git repository should contain a special file .gitignore, which specifies what files and directories to exclude.
Python and Pycharms: Git works really well in conjunction with Python and Django projects. The main file to exclude are the .pyc, compiled source code files.
Objective-C and Xcode: Xcode’s project file and resource nib files (.xib) generally cause conflict with Git. In fact, we usually separate each window into its own nib file so multiple developers can work on different screens at the same time. If conflicts do arise, we pick one copy and re-apply changes manually — this may be a painful process. The .m and .h files, on the other hand, work perfectly with git.