This is a collection of guides that show how to use gg’s commands in practice. If you are new to version control, start with Working Locally. The other guides show how to share your work with others; the one you need depends on how the project you are contributing to accepts changes.
Note: gg is a command-line program, so these guides assume you know how to use the command line for your platform.
Whether you are working by yourself or with others, the workflow for making changes on your local machine stays the same. This guide is primarily aimed at those who are new to version control, but is also useful for seasoned version control users trying to see how gg stacks up to their current tool.
The fork and pull model popularized by GitHub is the most common way to use gg. When using this model, the project has a primary repository that only the maintainers of the project have write access to. Contributors make changes by sharing a cloned repository (called the fork) with new branches. Contributors send pull requests to maintainers, who then review the code and merge in the changes.
In the shared repository model, the source of truth is a single
shared repository. This pattern is popular with individuals and smaller teams.
Each developer clones to a repository on their own machine and makes their
changes. When they are ready to share, they push to a branch on the single
shared repository. If they are using pull requests, each change goes onto a
distinct branch for review. Otherwise, usually commits go directly to the
default branch (e.g. main).
Some popular open source projects use Gerrit, a code review tool, to manage code contributions. Examples include Go, Android, and Chromium. Gerrit has a somewhat unique model for receiving changes that involves amending commits and pushing to specially formatted ref names. Developers using Gerrit usually build shortcuts on top of Git to manage this complexity, but gg has built-in support for Gerrit. gg makes working with Gerrit as easy as other Git workflows.