2023/01/18

Git version control system cheat sheet - life of a repository




The git distributed version control tool is one of the most popular versioning tools in use in the software industry today. It has a long history going back to 2005, created by Linus Torvalds for development of the Linux kernel. Git supports a distributed peer to peer workflows. Over it's history a number of processes like 'git flow' have been built on top of it and of course the famous github and it's related tools have become pervasive.

In this post I'm going to walk through the most common commands you need for your every day workflows from creation to distributing your changes.

Creating a git repository

Creating a git repository is a very simple. Git tracks all of your file changes by storing data about the state of the files in a hidden directory '.git' at the top level of the repository.

> cd some-directory
> git init
Initialised empty Git repository in some-directory

Cloning an existing repository

In reality you won't usually be initialising a repository from scratch, you will more than likely be 'cloning' a repository from some existing location. This will give you a full copy of the repository. This is achieved with the git clone sub command. Here is an example of how that might look if you were cloning a repository from GitHub:

> git clone https://github.com/SiteMorph/protostore.git

You can confirm that your clone of the repository was successful using the git status sub command.

> git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working tree clean

There are a few things to unpack in the status:

  • Git uses 'branches' to track multiple histories of a repository. There is a convention to use the 'master' as the parent / source for all other branches. Many git based workflows may also use the master branch as the destination for when changes are merged before being deployed.
  • There is also message about being up to date with origin/master. Origin is the remote machine label from where we just fetched the repository state. You can see what these repository locations are by calling git remote -v. Again by convention 'origin' is the default label for the remote location just cloned.
  • Nothing to commit is self explanatory. There are no changes to files being tracked by git.

Adding files to be tracked

After creating a repository with git init no actual files are going to be tracked by git so let's create one and add it to the files git is tracking:

> touch untracked.md
> git status
On branch master
Your branch is up-to-date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        untracked.md

nothing added to commit but untracked files present (use "git add" to track)

Adding your file to the set of those tracked by git is trivial with the git add sub command.

> git add untracked.md
> git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   untracked.md

Now we have a repo with a single tracked file which has uncommitted changes.

Committing a change to the log

Now that a change has been added to a file it's time to commit the change using the git commit sub-command. These sub-commands have a lot of options, you will pick up as you learn them. You can find out more about them using the git help commit sub command. Complete the prompts and you will now have a new checkpoint state in the log. Once the commit is in the log you can see the checkpoint commit states by using the git log sub command.

> git log
commit 8824fbd3e6djf8s5b20c893c9fe12d6dafecd647 (HEAD -> master)
Author: Bob Builder <youremail@gmail.com>
Date:   Wed Jan 18 22:13:58 2023 +0000

    Added a new file.

Resetting the state of the repository to some historical state

One of the most common questions about git is how to uncommit a set of changes. Git has a simple sub-command for this git reset however it's often not what you want to do as changes will be lost.

> git reset --hard 8824fbd3e6djf8s5b20c893c9fe12d6dafecd647
HEAD is now at 8824fbd Some commit message

Resetting a repository is a rather destructive activity and is almost the opposite of the point of having a version control system. Rather than resetting hard to a given commit, a more common workflow would be to copy the current branch with local changes. Above the HEAD is tracking the 'master' branch on the local copy of the 'origin' repository. Creating a copy of the branch before resetting it is probably a good idea. This is achieved using the git branch -c <your-new-branch-name>. You can then reset 'master' while keeping your changes on a different branch of the code. You can switch to that branch using the checkout sub command like git checkout <your-new-branch-name> and work there witout disturbing the master branch.

Pushing your changes to the origin repository

After some time you will build up a change log on your local repository and you will want to push it to another location to share or backup your changes. This is simple using the push sub command like git push origin. Note here that the origin remote location label is used again to push the current branch name to the remote host on the same branch name.

This post is intended to give you a flavour of the most basic commands, if you are interested in specific issues please comment below.

No comments:

Post a Comment