Rylee Alanza Lyman
September 28, 2021
As a mathematician, I collaborate with other mathematicians on papers. I’ve used Overleaf, emailing the paper back and forth, and taking turns in Dropbox as my mode of collaboration. I haven’t collaborated using Git, but I sure would like to. The purpose of this post is for mathematicians like for example my younger self, who are familiar with the command line and curious about Git as a tool, and for whatever reason don’t have the patience for something like “Git for Poets.” I explain Git just enough to get you started on a simple project, and hopefully enough so that you can start Googling things you’re unfamiliar with. I’m not an expert, and I expect my inexpertise to show.
Let’s start. There are two ways I typically start.
The first way is
that I have files on my computer that I would like to use Git on.
So I would open a command line,
cd over to where those files are (say
~/Documents/waver) and invoke
This starts a new Git repository in the folder you’re in.
The other way is some Git repository already exists
(probably on GitHub)
and I would like to work on those files.
In that case I would find the URL of that repository,
cd to the directory where I would like to put my copy of the repository,
git clone <url>.
This automatically creates a new folder with the contents of the repository,
so if I was cloning
ryleelyman/waver on GitHub, for instance,
and I wanted it to end up in
I would run
git clone https://github.com/ryleelyman/waver.git
Now Git is paying attention to the files in
but by default it isn’t doing anything to them at all.
You can see what it thinks by invoking
If you have files that have changed,
Git will display them (in red, in my terminal).
For example, when I run
git status in the
directory for my website, it tells me
Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: _site/blog.html modified: _site/feed.xml modified: _site/sitemap.xml
Git tracks changes based on “commits,”
but in order for something to be committed
Git needs to know that you want to commit it.
That’s the business of the
git add <file> comment above.
If we were to do
git add _site/blog.html,
we would be telling Git to prepare to commit
the changes we made to the
To actually commit the changes from there we would do
But! Don’t actually do
git commit -m "<message>".
Git commits require a little blurb from you about the changes,
and I find it much more convenient to just write that message
on the command line.
Now Git knows about our changes locally.
If we’re working with a remote repository, say on GitHub,
we still need to update that repository.
To do that we invoke
If you started the repository with
you may need to setup GitHub (or whatever it is)
to track the repository you created.
GitHub has nice instructions for this.
To update our local repository with changes from the remote repository,
we would do
Those are all the commands I use daily. I didn’t talk about Gits “branching” model, which is worth learning a bit about. I don’t know that I have anything cogent to say about it, so maybe I’ll stop here.