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 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.git
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.
1. Open a new terminal
2. Type in the command at the prompt:
ssh-keygen -b 4096
3. The user is prompted to save the key; we can use the defaults.
4. 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.
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:
git clone git@github.com:yetihq/AFNetworking-TastyPie.git
mkdir AFNetworking-TastyPie
cd AFNetworking-TastyPie
git init
git remote add origin git@github.com:yetihq/AFNetworking-TastyPie.git
git pull origin master
Now the developer should have a local copy of the repository on his computer.
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
Steps 1 and 3 are used when multiple developers work on the same repository. This step is unncessary for a single developer. These steps can be omitted in Tower because it will tell the user if stash/unstash are required.
Merge any conflicting source code changes, then:
git add .
git commit -m “some message describing the changes made”
git push origin master
Step 4 happens when two developers modify the same source code and the computer cannot resolve the conflict automatically. Source code conflicts should be resolved in Tower, a source code editor (e.g., Eclipse, Xcode), or a GUI text editor. The developer searches for <<<<< and >>>> in a text editor to resolve conflicting code. Conflicts can also be resolved in a terminal but I do not recommend that approach.
To choose which files to add, a developer can preview changed files using:
git status
For each modified file, type in:
git add <filename>
To review the change log in git, the following commands are handy:
git statusgit log
Again, I prefer using GUI tools for these tasks as it makes reviewing much easier.
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.
Git works really well in conjunction with Python and Django projects. The main file to exclude are the .pyc, compiled source code files.
Xcode's project file and resource nib files (.xib) generally cause conflict with Git. In many cases, we revert to one copy of the conflicting project file and then re-apply changes manually. The .m and .h files are exactly like C++ files, which work perfectly with git.