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:
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 firstname.lastname@example.org:yetihq/AFNetworking-TastyPie.git
git remote add origin email@example.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.
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:
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.
The Yeti team recently developed a new internal tool called "Yurt" - a command line application designed to streamline the process of setting up new code bases by incorporating our preferred preferences and patterns. Take a look at our article and video to learn how you can do the same!
Streamline workflows and boost productivity with AI powered software development! In this article and video seasoned software engineer James Feore discusses how how you can get the improve your development process with ChatGPT and Co-Pilot. Get ready to explore the transformative capabilities of Chat GPT for real-world applications.
Part of the Yeti Lunch and Learn series - our amazing developer, Resdan, gives a presentation on creating a reusable component library. Enjoy the video!