One way or another, git is what Sage uses for tracking changes.
So first, open a shell (for instance, Terminal on Mac) and check that
git works:

[[email protected]]$ git
usage: git [--version] [--help] [-C <path>] [-c name=value]...The most commonly used git commands are: add Add file contents to the index... tag Create, list, delete or verify a tag object signed with GPG'git help -a' and 'git help -g' lists available subcommands and someconcept guides. See 'git help <command>' or 'git help <concept>'to read about a specific subcommand or concept.

Don’t worry about the giant list of subcommands. You really only need
a handful for effective development, and we will walk you through them
in this guide. If you got a “command not found” error, then you don’t
have git installed. Now is the time to install it; see
Setting Up Git for instructions.

Because we also track who does changes in Sage with git, you must tell
git how you want to be known. This only needs to be done once:

Obviously one needs the Sage source code to develop. You can use your
local installation of Sage, or (to start without Sage) download it
from github which is a public read-only mirror (=faster) of our
internal git repository:

to tell the make program to run NUM jobs in parallel when
building Sage.

Note

Mac OS X allows changing directories without using exact capitalization.
Beware of this convenience when compiling for OS X. Ignoring exact
capitalization when changing into SAGE_ROOT can lead to build
errors for dependencies requiring exact capitalization in path names.

For the experts, note that the repository at
git.sagemath.org is where development
actually takes place.

In order to start modifying Sage, we want to make a branch of Sage.
A branch is a copy (except that it doesn’t take up twice the space) of
the Sage source code where you can store your modifications to the
Sage source code and which you can upload to trac tickets.

To begin with, type the command gitbranch. You will see the following:

The asterisk shows you which branch you are on. Without an argument,
the gitbranch command displays a list of all local branches
with the current one marked by an asterisk.

It is easy to create a new branch; first make sure you are on the branch from
which you want to branch out. That is, if you are not currently on the
develop branch, type the command gitcheckoutdevelop:

Once you have your own branch, feel free to make any changes as you
like. Subsequent chapters of
this developer guide explain how your code should look like to fit
into Sage, and how we ensure high code quality throughout.

Status is probably the most important git command. It tells
you which files changed, and how to continue with recording the
changes:

Once you have made any changes you of course want to build Sage and
try out your edits. As long as you only modified the Sage library
(that is, Python and Cython files under src/sage/...) you just
have to run:

as if you were installing Sage from scratch.
However, this time only packages which were changed (or which depend
on a changed package) will be recompiled,
so it should be much faster than compiling Sage
the first time.

Note

If you have pulled a branch from trac,
it may depend on changes to third-party packages, so ./sage-br
may fail. If this happens (and you believe the code in this branch
should compile), try running make.

Rarely there are conflicts with other packages,
or with the already-installed older version of the package that you
changed, in that case you do have to recompile everything using:

If you switch between branches based on different releases, the timestamps
of modified files will change. This triggers recythonization and recompilation
of modified files on subsequent builds, whether or not you have made any
additional changes to files. To minimize the impact of switching between branches,
install ccache using the command

Recythonization will still occur when rebuilding, but the recompilation stage
first checks whether previously compiled files are cached for reuse before
compiling them again. This saves considerable time rebuilding.

Whenever you have reached your goal, a milestone towards it, or
just feel like you got some work done you should commit your
changes. A commit is just a snapshot of the state of all files in
the repository (the program you are working on).

Unlike with some other revision control programs, in git you first
need to stage the changed files, which tells git which files you
want to be part of the next commit:

This will open an editor for you to write your commit message. The
commit message should generally have a one-line description, followed
by an empty line, followed by further explanatory text:

Added the last twin prime
This is an example commit message. You see there is a one-line
summary followed by more detailed description, if necessary.

You can then continue working towards your next milestone, make
another commit, repeat until finished. As long as you do not
gitcheckout another branch, all commits that you make will be part of
the branch that you created.