Git is used in software development projects of every kind. It has almost completely replaced earlier source code management tools such as CVs and Subversion. At the same time, it uses concepts that are difficult to understand.
Learning to use its many commands takes time, even for skilled developers. This piece doesn’t try to be a tutorial on using Git. Several good introductions for users are available. Here we’ll look at what Git does and how it organizes code that developers are working on. This will include a look at the GitFlow paradigm, a way of organizing Git workflows which have become widely popular. Anyone who wants to learn to use Git or understand it from a manager’s viewpoint needs to learn these concepts before plunging deeply into the commands.
The Basics of Git
The most important point is that Git is a distributed repository. Subversion and other earlier tools used a single, centralized repository. All developers checked their code out from the repository, made changes, and checked it back in. The repository allowed multiple branches, but they all resided on a central server.
Git lets each developer have their own copy of the remote repository. They clone it from the remote repository, make changes, and commit to their local copy. When they’re ready, they push their version of the repository to the remote. At any time, they can pull from the remote so that they’re up to date with changes that others have committed.
The local repository is a full copy of the remote one or one or more of its branches. It contains the full history of the branches, not just the latest version. A developer can create a new local branch, work in it, and merge back to the main branch before pushing to the remote repository.
Beginning to Use Git
When starting to use Git, a developer should customize it with the git config command. At a minimum, the configuration should have the developer’s name and email address, so that any changes that are checked in will be identifiable. It should also be set to ignore bookkeeping files which the operating system creates, so they won’t accidentally be added.
Developers need to know some basic commands to do this much. GUI tools for Git are available, but anyone who’s serious about it knows how to use it from the command line. Some of the first commands they’ll learn are:
- Git clone — Creates a local copy of a repository, and sets it up so that the developer can push and pull between the local repository and the remote.
- Fetch — Updates the local repository to match the remote.
- Pull — Updates the local repository and the working files.
- Push — Sends changes from the local repository to the remote. The changes are merged only if a “fast forward” merge is possible, meaning no one has made independent changes in the meantime. The preferred approach is to merge with the latest changes before pushing.
The Three Trees
A developer’s machine contains three places where files from Git are stored. They’re called the “three trees.” Understanding them avoids a lot of confusion in how Git processes changes.
- The HEAD in the local repository. The developer is always working in a particular branch, called the HEAD, at any moment. It contains files as they were pulled or fetched from the remote, or as the developer last committed them. A push will send the latest HEAD changes to the remote.
- The index. It stands between the working directory and the HEAD, and beginners tend to forget it’s there and not understand why their changes aren’t being committed. The developer needs to add files to the index before committing them.
- The working directory. The files here are available to edit, compile, or run. The developer can make any amount of changes, test them, and throw them away without affecting the index or HEAD.
To move edited files into the index, the developer uses the git add command. Only then is it possible to move them to the HEAD, using git commit.
GitFlow
Managing source code for regular releases requires being able to work on features separately from one another and not letting versions collide. The GitFlow process is a popular way to do this. A team can use it without any extra tools, though a package of extensions is available to simplify its steps.
The central repository uses two permanent branches. One is the usual Master; the other is the Develop branch. The Master branch is used for nothing except the production code. A code is checked into Develop before going to Master.
Each feature which developers are working on gets its own branch. They branch off from Develop, not from Master. The work on the feature is done in its own branch, then it’s merged into Develop.
Moving on to Production
When it’s time to move to production, a release branch is forked from the Develop branch. It shouldn’t get any major new code, but it’s where any remaining bug fixes and documentation enhancements will take place. When it’s ready to go, it’s merged back into Develop as well as Master. The current state of Master is tagged with a name of the form “release-x.y”. This is the code that goes to production. New work on the next release can then start by pulling code from Develop.
Sometimes it’s necessary to fix code after it’s been released. In the GitFlow model, this is called a “hotfix.” Developers can create a hotfix branch for this purpose. Only hotfixes branch directly from Master. After making the necessary changes, they check the hotfix back into Develop and Master. The fixed version is tagged with a patch release number, using the form “hotfix-x.y”.
Developers can make feature branches, but only team leaders should create release branches. Leaders should also handle all merging into Develop and Master.
GitFlow isn’t the only workflow that’s possible with Git, but it’s effective in coordinating large projects.
Learn More About Git
Authoritative documentation on Git is available on git-scm.com. A free ebook, videos, and pages on individual commands are available. The help pages on GitHub are another useful resource, especially for developers using GitHub as their primary repository. Codecademyoffers a free introductory course.
Managers who deal with software teams need to understand the language of Git, even if they don’t personally use it. Knowing what it’s all about will help in understanding and planning development and release processes.
There’s always more to learn. The team at Entrance Consulting puts on regular “brown bag” lunch sessions where a team member leads a discussion on a chosen topic. The subject could be tools, languages, or the art of dealing with emergencies. Everyone contributes from their own experience. Participants talk not only about the technology but the real-world issues involved in using it. This makes us keep our own skills sharp, so we can better serve our clients.