Git Cheat-sheet

This is a quick command-reference for using git on the command-line. While there are indeed many UIs for git, and of course, all IDEs worth their salt have git integration, it is highly recommended to get proficient with the git command-line. It is powerful, for the most part, relatively easy to use, mostly (not always!) intuitive, and very fast.

So, without further ado, onto the cheat-sheet.

Initialising a git repository

For a new project, you’ll need to first initialise the git repository locally. You can do this by running:

git init -b main

This will initialise your local repository and set the main branch name to main.

The git main branch name

The main branch was historically called master - however, most of the world has moved on to calling in main. In older versions of git this was actually hard-coded within git - so there wasn’t much of a choice! But current versions allow you to choose your main branch name. My git-server is setup to default to the name main, and from git version 3 onwards, this will be the default setting. For this reason, I’ve also started setting up new projects with the main branch named main. Old projects created with the master main branch name, will retain that name.

Once initialised, you can add select files (or all!) and commit:

git commit -m "My first commit"

This commits your changes locally.

To push to a remote git server, you need a remote setup. You can add a (single or multiple) remote(s) by:

git remote add origin REPO_URL

🛈 Note

The remote must also be initialised to a bare empty repository. This can be done by running git init -b main on the git-server. You obviously need access to the git-server in order to do this!

Now, you can push:

git push

This pushes to the default (usually single) upstream remote.

🛈 Where is my repository on athena?

All git repositories are organised under repositories/project.name. Your repository URL will always be: git@athena:repositories/project.name.

Multiple remotes

You can have multiple remotes (see git push documentation). This is useful if you run your own git-server, as I do, and want to use one of the public git servers like GitHub as a backup repository.

To add another remote, it’s the same command as above, just change the name from origin to something specific to the other remote - or use indicative names for all remotes you want to use.

git remote add <remote_name> REPO_URL

You can see all your remotes by running:

git remote -v

If working with multiple remotes, it is sometimes useful to setup remote groups so that pushes can be automated to all remotes within a group. To do so, in your repository root directory, run:

git config remotes.all-remotes "origin origin.github"

Now you can simply run this command to push to all remotes in the all-remotes group.

git push all-remotes

Working on branches

Generally, work is done on a branch, and when ready, merged back to main. To create a new branch use the following command:

git checkout -b <branch_name>

This creates and checks out the new branch.

🛈 Branch naming convention

Normally, branches are named according to the type of work. So for adding a feature. the branch name would be prefixed with feature/, and for bug-fixes, with bugfix/.

Once created push it - it will fail, but will tell you how to fix it.

git push -u origin feature/<branch_name>

This pushes the new branch to your upstream remote, and sets up the local branch to track the upstream remote branch.

Commit changes normally, and when ready, the branch can be merged back to main.

Merge considerations

When working on a branch, on a collaborative project, obviously main may change due to other changes coming in. Normally, you’d want your merge to be linear in time - so after any changes that might have happened before, rather than interspersed. To keep a clean, linear timeline, you should always rebase your branch on anything that might have come in. Git offers a rebase command:

git pull --rebase

The usual process is:

• Stash your changes, switch to main and rebase.

git stash; git checkout main; git pull --rebase

• Next, switch back to your branch, and merge main into it.

git checkout feature/<branch_name>; git merge main

• If there are no conflicts, you can commit this merge. Otherwise, resolve conflicts, if any. Use a graphical tool to do this - most IDEs will offer a 3-way merge tool.
• Commit and push your changes.

Following this process maintains a linear commit history and places your changes after any incoming changes (when you merge back to main). This is important to preserve linear change history.