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:
Granting 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.
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.
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:
git clone email@example.com:yetihq/AFNetworking-TastyPie.git
git remote add origin firstname.lastname@example.org:yetihq/AFNetworking-TastyPie.git
git pull origin master
Now the developer should have a local copy of the repository on his computer.
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.
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
>>>> 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:
For each modified file, type in:
git add <filename>
Reviewing Changes in Git
To review the change log in git, the following commands are handy:
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 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.