Git commands to get you through the day

Mar 12, 2021 · 7 min read
#tooling #git #version-control #workshop

Since the start of the year, I’ve been running weekly workshops with Paddy Morgan at work. These have been fun sessions to run. Some have been chats, some demos etc.

However, this week we ran a “Git 101” workshop. Weirdly, this was the most attended workshop we have run, with around 50 engineers joining throughout the hour session.

This post covers what we ran through.

Time allocation: 60 minutes

This workshop will be a high level overview of the basic git commands you will use daily. It’s an entry level workshop, so if you’re comfortable with git on the CLI, this probably isn’t for you.

If we have time (intermediate)

Notes

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Source

Disclaimer

There are different ways to achieve the same thing. Here are some cheat sheets:

Cloning

Git is a distributed version control system, so doesn’t require a centralised server. You can clone from another machine on a network, GitHub, GitLab, or your own git server.

For this example, however, we will use GitHub.

git clone https://github.com/benmatselby/dotfiles.git

git clone gets the codebase from GitHub, in this instance, and keeps a copy on your machine. You have now “cloned” the repo.

How do you know where the original end point is?

git remote show

This will show you the origin remote in the first instance.

git remote show origin

This gives you all the details of the origin remote. What the URL is etc.

But, you can have many, many origins.

git remote add github https://github.com/benmatselby/dotfiles.git
git remote show
git remote show github

This adds another remote, called github that points to the same endpoint, in this example (which is contrived).

Fetching

Git is a distributed version control system. So you have the full repo locally, but changes are being made elsewhere. You need to fetch those changes.

Benefits of this include being able to work “offline” and still commit code. You do not need an internet connection to commit code!

git fetch origin

This pulls the latest information from the origin remote. This includes branches, tags etc.

But,

git fetch github

Also fetches from the github remote.

Pulling

So, we have cloned and fetched. Now we need to pull the code into your branch.

git pull origin main

This pulls the code from the origin remote, and the main branch. You can change both of these values to match your remote and your branch.

At this point, you are “up to date” with what is on the server, wherever that server is.

Branching

You have a clone, you have the code, now you want to change it.

git checkout -b workshop origin/main

So git checkout is the command. -b is the option to create a branch. workshop is the name of the new branch. origin/main is what I am branching from. It can be from any remote, or branch. You can even create a branch from a local branch:

git checkout -b workshop main

Committing

You’re on your branch, you’ve made some changes, now you need to commit.

We have a few options here:

git add .

This can be risky, if you are not overly disciplined on file management, or working logically.

or

git add [file] [file]

This can be better as it allows you to pick the files to stage, ready for commit.

Both of these options have staged files ready to be committed.

How do you know what to commit?

git status

This shows you what is and is not staged, and what will be committed.

Again, a couple of options:

git commit -a

Again, this can be risky, if not overly disciplined as it will commit all changes you have made. This is the equivalent of git add . mentioned above.

or

git commit

Other options:

Soap box:

Pushing

Committing code, does not make it available for everyone, since git is distributed. So, we need to push the changes

git push origin workshop

So git push is the command. origin is the location of the server we want to push to. workshop is the branch we are pushing to.

Rebasing

So you now commit all day long, but at the end of the day, you want to make logically atomic commits. This means you need to learn rebasing.

I always think of rebasing as “replaying your work over the top of the latest code changes on the branch”.

But you can also do much more with an “interactive rebase”.

Normal rebase:

git rebase origin/main

Interactive rebase:

git rebase -i origin/main

Interactive rebase provides you a menu of options, such as squashing, picking, editing, dropping.

Configuration (Global and repo level)

git config --list will show you all your configuration items.

You can break that down

So to add config

git config --add user.email [email protected]

This sets configuration locally to the repo you are in, and overrides global configuration.

To unset configuration

git config --unset-all user.email

Or to add configuration globally

git config --global --add user.email [email protected]

You can also edit ~/.gitconfig for global configuration, and .git/config for the local repo configuration.

Let’s say you want to have version controlled git configuration, but you need different email addresses (e.g. one for work, one for home), you can set the following:

[include]
  path = ~/.gitconfig.local

The contents of ~/.gitconfig.local:

[user]
  name = Ben Selby
  email = [email protected]

Logging

Logging is what it is, but here are some useful commands:

Hooks

The book.

Note that there are server and client side hooks. If you maintain your own git server, you can have both. If you use GitHub, you have “GitHub Actions” as the server hooks.

Normally, we deal with local hooks, which are stored in .git/hooks.

Tidbits

See also

Content

Social

Recent