Why You Should Consider Using Git, Even If You Are a Solo Developer
by: Fred Morgan
If you work with open source software then I’m sure you have already learned how challenging the process of upgrading applications can be (if not, you will soon enough). After recently upgrading a Drupal 7 installation for a client, I found an issue with the way links were being rendered in a particular view (the query string parameters were being mysteriously removed). The settings in the view had not been corrupted by the upgrade, so I decided something in the upgraded code base must have caused the issue. However, since a standard Drupal installation contains thousands of files, searching for the offending code would be worse than trying to find a needle in a haystack.
Enter Git. At its core, Git is a version control tool for software developers who work in a distributed development environment that allows multiple developers to work on a single project without stepping on each other’s code. The web developers at eXcelisys use it precisely for that purpose. However, it also has many useful features even if you are the only developer working on the project. Not only does it allow you to maintain discrete versions of the application you are developing, it also has a built-in tool for comparing files, called “diff.” This tool will reveal the files that have been modified between commits and show exactly which lines of code were changed. You can even view the modifications side-by-side to help you sift through the changes and identify the bug that was introduced in the latest version.
The downside to using Git is the learning curve, especially if you use it from the command line. In fact, just perusing the Git reference can be an intimidating experience if you’re not accustomed to working with the terminal. The good news is, because of its popularity in the open source world, there are a variety of services and GUI clients available to help with this process, which means you don’t have to learn all of those cryptic terminal commands. Github (www.github.com) is the most popular of these services, and offers hosting for free public repositories. It is wildly popular in the open source world, and for good reason. In fact, if you have spent much time in open source development, you have probably been introduced to using git by downloading files from Github without really understanding what it is or how it functions. However, if you are working on a project for a client, a public repository is probably not the best idea. This is where alternatives like Bitbucket are more appropriate. Bitbucket offers the same features of Github but with unlimited private repositories for up to 5 developers on any one project. (If you are interested in more information regarding the basics of using Git, there is an introductory video that can give you a quick overview).
This tutorial will walk you through the steps of using git to create a private repository and to compare the changes in commits (versions of your code base).
- Create an account at bitbucket.org.
- Login to your account and click the Create button.
- Enter a name and description for your repository, along with the remaining options shown in the following image, and click the “Create repository” button.
4. Using Git can be a complicated process, but it is much easier with a GUI client. Click the link to download the Atlassian Source Tree client and install the software on your system. Configure the software with the user credentials for your Bitbucket account, then return to your browser and click the “Clone in Source Tree” button.
If you see a dialog prompting you to select an application, select Source Tree and click the checkbox next to “Remember my choice for sourcetree links.”
- Enter the destination path for where you would like to store the repository files and click the “Clone” button.
- The repository will be cloned to your local system and Source Tree will open a new management window for the repository.
- The window will tell us that there is nothing to commit because we haven’t yet added any files to our local repository. Navigate to the folder you set up for the repository or click the “Open in Finder” button and copy the code for your build to this location. For simplicity’s sake, I am only going to copy the affected module (in this case, Drupal’s link module). For the first commit, I want to use the module as it was prior to the upgrade procedure. So I am going to copy the entire folder for the link module.
Next, return to your Source Tree management window and you will see a list of the files you have copied which will appear in the Unstaged files area.
8. Click the checkbox next to “Unstaged files” and the client will move all files into the Staged files area.
- Click the “Commit” button at the top of the screen and enter a description for the commit. Select the “Push changes immediately to origin” checkbox (this will save us a step) and click the commit button at the bottom of the screen.
- This action will create the commit and push the files to the repository. In the left navigation pane, select “master” under “Origin” to view the details of the commit.
- Now simply copy the link module from the post-upgrade installation into the folder, replacing the existing folder in that directory on your local machine.
- Return to the Source Tree management window and you will once again see a list of files in the “Unstaged” files pane. Repeat steps 8 and 9 above, but this time enter a description that identifies this commit as post-upgrade.
13. Repeat step 10 and you will see that you now have two commits under “master.”
- Now return to Bitbucket.org in your browser and click the commits link for the repository you created in the left navigation pane.
- Select the latest commit (post-upgrade) and you will see a list of files that have changed. Scroll the window down and you will see each of the changes; green indicates lines that have been added and red indicates lines that have been removed.
Clicking the “Side-by-side diff” button can make the code comparison even easier. In my case, the issue was found in the link.module file. Once the issue was identified, I was able to locate a patch for the module in the current development version of Drupal 7.x. The expected behavior was restored after replacing the module with the patched code.
This is one of countless applications of the powerful diff engine in Git and a great example of why you should use Git, even if you’re a solo developer. This functionality is also very useful for finding infected files in a compromised site, checking the modifications you made in various versions of an application, or just tracking down bugs in your own code.
Using Git in your development workflow can deliver a real productivity boost when attempting to pinpoint file changes, even if you are a solo developer. Happy hunting!
**This article is provided for free and as-is, use, enjoy, learn, and experiment at your own risk – but have fun! eXcelisys does not offer any free support or free assistance with any of the contents of this blog post. If you would like help or assistance, please consider retaining eXcelisys’ consulting & development services.