Git (and version control in general) is one of those things that can take time to understand why you need it. But once you do, you’ll never want to live without it. If you’re not sure if you should be using a version control system, ask yourself if you ever work in teams, make mistakes, or lack a perfect memory of everything you do. If you answered yes to any of those questions, I recommend you use a version control system.
A version control system, such as Git, tracks every change to the content of a version control repository—a theme, a plugin, or an entire WordPress site, for example. Because the system knows what changes occurred, and when and who made them, you have the power to undo or redo changes. Version control system also give you the power to create an infinite number of “branches” that can be managed independently, and “merged” into one later.
While there are other version control systems out there, Git is the most popular in the WordPress ecosystem. Even if WordPress core development and WordPress.org still stubbornely, uses subversion for version control. Git’s popularity is due to the ubiquity of the popular Git host GitHub, with its great UI, as well as the number of quality GUI clients available for Git.
This article will introduce some basic Git terminology and tools. I will also discuss how to implement a good workflow for individuals and small teams. Implementing a workflow requires having the right tools, so let’s begin by discussing. Finding the workflow that makes sense for you or your team is important because with great power comes great responsibility—and Git is no different. If you’re not careful, especially when working in teams, you can cause some real headaches for yourself, most often in the form of merge conflicts. But with an established workflow and good project management these can be avoided.
While Git can seem complex and has a lot of really powerful options, the basics are actually quite simple. Every project is contained in a “repository” that contains one or more branches. All changes or “commits” must occur on a specific branch. Branches can be merged together with a special type of commit called a “merge.”
When working with a Git repository, you make changes to your local copy, and typically “push” your changes to a remote hosted repository. Each “push” merges your local changes with the remote repository. Alternatively, in order to stay in sync with the remote repository, you will often merge the remote changes into your local repository.
In some cases, the merge can cause a “conflict” that occurs when Git cannot determine the best way to merge changes, as there are one or more ways it could be accomplished. In these cases you will need to manually choose between the options. The goal of having an established workflow is to limit the possibility of a conflict from happening.
Git Hosting Options
While your Git repository will exist on your personal computer, in order to work with multiple people you’ll need to have a remote host for your repository. Even if you are not working with others, a remote host creates an invaluable backup of your code. In addition, deploying code to your live server from a remote host is generally a better option than doing it from your own computer. Especially when working in teams.
Choosing the right hosting option for your Git repository is the first step in establishing a proper workflow. There are a lot of options for Git hosting out there. Which one you choose will depend on your budget, and how it integrates with the project management and chat tools that your team relies on.
Hosting your Git repository on your own server is always an option, but there are many benefits to using a Git hosting service. The popular Git hosts include GitHub, GitLab, and BitBucket—all of which include a browser based UI, making it easy for you or someone else to browse your code and even edit it or submit a pull request. Most Git hosts provide an issue tracker, which can not only be useful for tracking the work that needs to be done for your project, but also to accept bug reports and even support requests from users.
GitHub is probably the most popular choice for Git hosting. Today more and more WordPress users, developers and non-developers alike, are accustomed to using the GitHub interface to download or clone a plugin or theme, as well as to use the issue tracker for bug reports.
While GitHub offers private repositories as a paid service, BitBucket offers private repositories for free—making it a popular option for hosting premium WordPress themes or plugins, and storing site code. In addition, BitBucket is a service provided by Altassian as part of their complete set of tools for creating software in teams. These tools include the popular chat app HipChat, which is a great example of a chat tool with tight integration with Git.
While Git is a tool designed to be used from the command line, many users will never have to open their terminals when using Git thanks to a crop of excellent, mainly no cost, GUI tools. These GUI tools make it easy to learn Git and manage your code. In addition they provide an excellent way to visualize the Git tree for your repository. Making it easy to use Git is a key step in ensuring that members of your team are able to follow through on the obligations that the agreed upon workflow requires.
Probably the simplest Git client is the GitHub app for Mac or Windows. It provides tight integration with GitHub hosted repositories and the most graphical of the various GUI options I am listing here. While it lacks some of the more advanced features of some other Git GUI clients, it really is aimed at making Git easy for beginners. If you are totally new to Git, the GitHub app might be a good choice.
For a more fully-featured Git GUI client, one good option is SourceTree, from Altessian, which I mentioned earlier. SourceTree, like the GitHub app is free and supports Mac and Windows. SourceTree integrates easily with repositories hosted on GitHub as well as BitBucket, as well as those hosted elsewhere, such as your production site. Other options include Tower, a paid client for Mac, and Git Cola, which is GPL licensed, and supports Mac, Windows, and Linux.
Other Important Tools
Implementing and managing a successful Git workflow comes down to two important aspects: communication and integration. There are a growing number of project management and chat tools that integrate with popular Git hosts such as GitHub, GitLab or BitBucket. While most Git hosts include an issue tracker, an issue tracker shouldn’t be confused with a project management system.
When selecting a project management system, be sure that it has integration with your Git host. You will want to make sure that mentions of issues or commits in your project manager will automatically link to the issues or commits. The ability to open and close issues from your project manager is also key to ensuring that project management makes your life easier and more efficient, instead of making it more complicated.
Teams thrive on communication. Chat tools that integrate with Git host integration are invaluable. The ability to mention an issue and have the link automagically appear in the chat, or to have links to mentions from chat added to your issues are also important integration to look for when choosing your tools.
The key to avoiding Git conflicts when working in teams is to have a defined workflow, and a proper project management system. The internet is full of different systems to use. It’s important to use one that works for your team, and isn’t overly complicated.
It’s important to think of a Git workflow as an agreement. I say this because everyone involved is agreeing to follow a procedure designed to prevent conflicts. Like any agreement, it only works if everyone follows the agreement. In addition, a poorly designed agreement can lead to conflict.
In some cases, like when you are working on a project by yourself, or one that isn’t public-facing, there is no need to make branches. For example, on one project I am currently working on with one other developer, we are both committing directly to the master branch. There is no risk of conflicts because I am creating custom plugins to add functionality to the site, while the other developer is working on design and implementation. As a result we will never be editing the same files.
The simplest workflow is to keep the master or default branch as the stable release. In this strategy, changes are only made to the master branch by merging a “develop” branch or a branch named for the version under development,into the master branch. In this workflow, all development occurs on the development branch, which is not the default branch.
Not developing on the default branch is especially important when the repository is public. A public repository’s default branch is often a source for your users to clone or download your code (or even to install via a package manager such as composer). Having an explicit “develop” branch makes it clear that particular branch is not to be used in production. Even if your code isn’t public, you are likely to need a branch that you can safely deploy to your site or deliver to your customers without worrying that the latest change to the develop branch will break the live site.
This basic master/develop branch system can be expanded by many levels based on your needs, the complexity of your project, and the size of your team. In these systems, think of the branches that split off from develop as existing below it, and that changes work their way up to the main develop branch.
One way to implement this, which works well with agile management strategies, is to add an alpha or beta branch, and at the beginning of a sprint to branch that branch. All changes are committed to the sprint branch. Once the sprint is completed that branch is merged into the alpha/ beta branch. This strategy results in a the alpha/beta branch being updated once per sprint, with each update representing a alpha/beta version.
Once the alpha branch is completed, it is merged into the beta branch and the process continues to work its way “up” to the develop branch.
Alternatively, with non-agile project management systems, you can create different branches of the development branches for each feature or issues, group of features or issues. For example, a branch might be “admin-ui-improvements” or “issue-with-archive-templates”. This strategy works well for long-term projects, but requires pre planning to ensure that each project doesn’t work on the same files or the same section of each files.
No matter what strategy you choose, the goal of project management has to be to ensure that two team members are not working on the same part of the same file, in the same branch at the same time. In larger teams this may require creating branches of individual issues and assigning a team member, who is experienced in using tools for automated merge conflict resolution, to handle merges.
Making Git Work For You
Each of these strategies has its own advantages and disadvantages, and it will take time to figure out which one is best for your team. Keep in mind that Git is a safety net. There is no mistake that can’t be undone, which is the beauty of using Git. Even if you’re the only one working on a project, I strongly recommend using Git. Personally, Git is part of why I have confidence to do the work I do, knowing that I can’t break anything permanently.
I’ve only scratched the surface of what Git can do. If I missed a tool that makes Git even more useful and powerful, or if you have a different workflow strategy that you’d like to share, please leave a comment explaining it!