The Git Workflow
Working by yourself on a project with no version control, you hack a little, test it out and see whether it does what you want, tweak a few more lines of code, and repeat. Adding version control into the mix, you start committing those tweaks to keep a record of them. The high-level overview of Git’s general workflow is shown in Figure 1, The Git workflow.
Figure 1. The Git workflow
My Standard Workflow
My standard day working with Git goes something like this: I fetch all the changes from the other developers on my team to make sure I’m working with the latest code, and then I start working on the user stories I have for the day. As I make changes, I create a handful of commits—a separate commit for each change that I make.
Occasionally, I end up with several separate changes that all need to be committed. I’ll break out Git’s patch mode, stage, and finally commit each set of changes separately.
Once I have the feature complete, I give the commits I’ve created a quick review to make sure all the changes are necessary. At this point I look for commits that can be combined and make sure they are in the most logical order.
Finally, once I have those commits ready, I share those commits by pushing them (push is the term for sending commits to another repository) back upstream to my public repository so the rest of the team can view them and integrate them with their repositories.
Small Teams with a Shared Repository
Many small teams use Git like a traditional version control system. They have one main repository that all the developers can send changes to, and each developer has their own private repository to track their changes in.
You make your changes locally; then when you’re ready to share them with other developers, you push them back to the repository you all share.
If someone else has shared their changes since the last time you updated from the shared repository, you will get an error. You must first get the changes from the shared repository and integrate them into your repository through a process called merging. Once the changes are merged, you can push your changes to share with the rest of the team.
Git in Open Source
Each open source project has its own methods of accepting changes. Some projects use a fully distributed model where only one person can push changes to the main repository, and that person is responsible for merging changes from all the contributors into the main repository.
Having only one person capable of pushing changes is often too demanding a job for a large open source project. Many have a main repository that all of the committers can send changes to.
The main developers encourage people who are just starting out to fork their project—create a copy of the repository somewhere else—so the main developers and other members of the community can review their changes. If they’re accepted, one of the main contributors merges them back into the project’s repository.
These different scenarios constitute different repository layouts. Git allows several different layouts, and covering them deserves a section to itself.
Repository Layouts
The distributed nature of Git gives you a lot of flexibility in how you manage your repositories. Every person on your team has their own private repository—the repository that only that person can update. However, there are two distinct ways to handle public repositories. For a visual explanation of these layouts, see Figure 2, Shared and distributed repository layout with three developers.
Gray circles are the private repositories; outlined circles are public repositories.
Figure 2. Shared and distributed repository layout with three developers.
One method is the fully distributed model. In this, each developer has their own public repository that the developer uses to publish their changes to. All the other developers on the team then pull changes from everyone else’s repositories to keep current.
In practice, most teams have a lead developer who is responsible for making sure all the changes are integrated. This limits the number of repositories you and your team have to pull changes from to one, but it increases the workload on the person who has to integrate everyone’s changes.
Another method is the shared repository model, where all developers can push to a shared repository. This resembles the standard centralized model and is often adopted by teams when they first start using Git—it requires the least amount of mental overhead when it comes to thinking about where a change is shared.
You can mix both of these as well to create a hybrid solution. Use a shared repository for all of the code that’s ready for production, and each developer maintains their own public repository for sharing code that’s still a work in progress. This is the model I’ve employed successfully at my company and that’s used by many open source projects—push final changes to the main repository, and keep experimentation in your own repository.