Git, GitHub, GitLab

Controlling the development and administration of your digital product

git – form of version control

version control is a way of trying to ensure that changes are controlled as a product is developed. At its simplest it is commenting on changes as they are made on a single file by a single person in a single location. At it’s most complicated it many changes, by many people in different locations and possibly different companies.

Basic setup and first commit

1. Check git is install by typing git –version in my version: git version 2.39.5 (Apple Git-154). Once git is install or if it’s already installed we need to record the user doing the committing and the email address of that user.
Type git config –global user.name “John Does” and
git config –global user.email johndoes@email.com

There is a file called gitignore which tells git to ignore those files. We won’t cover it here but just so you ar aware that it’s there for that reason.

2. Pick the directory (another name for a folder) or make a new directory (mkdir) that you want to track or create a new directory by typing git init. This installs all the tracking files that git uses to track changes in the folder when the files have been told to be tracked. The git files and folders are ‘hidden’ to avoid the files being confused with working files. For this example we will use a directory called gitPractice with a text file called test.txt. The file has one file already added ‘this is a test file’.

this is a test file

With the folder initialised changes to the files are not tracked yet. At this point files are “untracked” which means git knows the files are there but is not tracking any changes. Untracked is one of four states a file can be in (untracked, Changes to be committed (staging), committed). In this example we have one file test.txt

git status

On branch main

No commits yet

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

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

3. Add the files you want git to track with git add test.txt

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
       new file: test.txt

When a file is added it means the file is added to STAGING. Staging is the place before the file gets committed. Files that are in staging (Changes to be committed are in green.

4. Commit the file to the repo to create a snapshot save of the file at the time of the commit by typing git commit text.txt -m “first commit”. You will get something like the following.

[main (root-commit) 7d16d77] first commit
1 file changed, 1 insertion(+)
create mode 10064 test.txt

5. Check the status of the repo with git status

On branch main
nothing to commit, working tree clean

6. Check the log of the repo by typing git log. This completes taking a new file and recording a version to git. You will be able to go back to this version at any point. We’ll have a look at the HEAD -> main in a bit

commit 7d16d77d5a172b2e3dfda2cd4587286f835c3433 (HEAD -> main)
Author: John Does <johndoes@email.com>
Date:   Sat Jul 26 23:57:16 2025 +0100

    first commit

7. We want to change the last message so it looks a bit better from ‘first commit’ to ‘First commit’ by typing git commit –amend -m “First commit”. This changes the message in the log from ‘first commit’ to ‘First commit.

Second commit, restore from staging

Now that we have a file committed to git we can make changes to it and save it as we go. This is the same as saving a new version of a file when we have made changes. The difference is that we are not storing a whole copy of the file but just the changes. Let’s add something to our test.txt and see how git handles it.

8. Open the test.txt in application of your choosing. We are going to use a command line text called nano which allow us to stay in the command line. Type nano test.txt which will open the editor. Add the following line Welcome to Learning Git. This will mean the test.txt looks like this:

Welcome to Learning Git

This is a test file

Save the file and go back to the command line.

9. Check the status of the file that has changed – git status

On branch main
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:   test.txt

The file has moved from committed to modified and is in the working directory (the state where a user is working on it – think of it like going to the directory and seeing some one has checked it out as it working on it).

10. Check the difference between what is in the working directory and what is in the repository by typing git diff. git diff means show the difference between two files.

diff --git a/test.txt b/test.txt
index 493021b..4d92cbb 100644
--- a/test.txt
+++ b/test.txt
@@ -1 +1,3 @@
-this is a test file
+Welcome to Learning Git
+
+This is a test file

You can see that the line that has changed in red (line deleted or moved) and what’s been added in green (something new or something been moved to this position)between the two versions of the same file. We are happy with this change so we can stage than commit. If we were not happy with the change we would type git restore –staged test.txt. This would mean if someone wanted to commit all the changes that can been made it would not include this one (only files that have been staged can be committed)

11. Add the file back to staging by typing git add test.txt. This adds the file to staging. Here we are telling everyone watching that the file is ready to be committed. We could commit files straight away but we hold files in staging so we can commit a load of files in one go so we don’t have loads of commits.

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   test.txt

Commit the changed test.txt by typing git commit -am “Added title”.

[main faabbad] Added title
 1 file changed, 3 insertions(+), 1 deletion(-)

The commit shows on the first line what branch the change was made on (main) with the code for the commit (or the hash) along with the message of the commit. The second line shows how many files were committed and how many changes – 3 lines where inserted and one deleted (moved which counts as a deletion and insertion).

Check the log of the commits with a little more refined way of checking the logs with git commit –oneline which gives

faabbad (HEAD -> main) Added title
6874133 first commit

You can see from the two commits the 2 hashes from the two commits. We will need these to revert a change that has already been committed.

As a reminder: 1) untracked – git not tracking, 2) modified (not staged) – git is tracking knows the file has changed, 3) modified (added, in staging) and nothing as everything has been committed.

Some commits are more important than others say for a feature. We can make a commit standout by using a tag. Easy to add by typing git tag -a v0.1 -m “New minor version”. This will add tag to the top line of the commit.

Reverting a commit

OK. Let’s use git for what it’s for and that is to revert to an earlier version due to an error. Open the test.txt file up and add a line below ‘To commit something in git you type: gip commit -f “gip message”‘. This would give the following contents.

Welcome to Learning Git

This is a test file

To commit something in git you type: gip commit -f "gip message"

Commit this change to repo through git commit -am “git commit instruction” (we could write -a -m). Check the status of the log and you should get.

00c430a (HEAD -> main) git commit instructions
faabbad Added title
6874133 first commit

We now have a problem – the file has a mistake and so we need to go back to the version which does not have the addition (and yes, we could just delete the line and recommit).

First we check what the difference is between the files (imagine we have a problem in our application from a commit so we need to know what is different in our commit). Type git diff 00c430a faabbad (these are the last two hash values from the log. This shows:

diff --git a/test.txt b/test.txt
index f557990..4d92cbb 100644
--- a/test.txt
+++ b/test.txt
@@ -1,5 +1,3 @@
 Welcome to Learning Git
 
 This is a test file
-
-To commit something in git you type: gip commit -f "gip message"

Here we can see that the command to make a commit is incorrect so we need to go back to the earlier version. Here we have a lot of options.

The first thing we can do is undo the commit by reseting the git commits to the earlier one. We do this with git reset –hard faabbad using the hash of the commit we want to go back to.

git reset --hard faabbad
HEAD is now at faabbad Added title

If you check the test.txt file then you will see that the line is no longer there as we have gone to an earlier version before the wrong commit was made. This reset –hard [commit hash] may be over dramatic for a small change or not possible if the commit contained many files so there is another way of overriding the commit and the best way of doing that is through creating a branch.

Branches

We now know how to commit a change to git and how to revert to an earlier version of the directory. This is handy for a single person making changes to a single file. But when it comes to multiple files things get a little trickier but we can work of one copy in the same way that if you were writing a book we could work on different chapters at a time and there would be no conflicts as long as we didn’t need to have the whole book. But there are times when we need to access the whole book so we need to take a copy of the whole book.

Let’s say we didn’t have git and we have two people (Ann and Bob) working on the book. The book has two chapters with Ann working on chapter 1: History of Git and Bob on chapter 2: Getting Started with Git. Without git both Ann and Bob can work separately on each chapter managing their own changes. Or both can have all the chapters so they can see changes that are made so that they can reference each others work. It would work that every day Ann and Bob would take a copy of both chapters, make changes, then when ready check back in when changes have been made. As long as they don’t clash it all works.

So far we have worked this way with a single directory. In git this is called main or master. In coding we make copies of the program files and start working on them and then check them back in. As the directory is copied and then checked back in with changes this is called branching like the branching of train tracks from a main line to smaller lines (branch lines) with the idea the branch lines merge back into the main (or master) line at certain points along the way. We’ll get to merging later but for now think of starting the day on the main branch during the day and then moving back to the main branch at the end of the day.

With the idea of train lines there are three main git commands we need to be aware of

git branch < branch name > – creating a new branch
git merge
git branch -d < branch name >

To work with branches we will use the directory to build a small website that will consist of some pages, images, stylesheet and some javascript.

The end structure will be

index.html
images/logo.png
styles/stylesheet.css
script

But to begin with let’s start with just the index.html.

<html>
<head>
<title>Learning Git</title>
</head>
<body>
<h1>Welcome to learning Git</h1>
<p>Git is a great way to manage your digital product through managing changes of all the files that make up the project. On this site you will learn all about how git works</p>
</body>

The first thing we are going to do is change the index.html. Now, we are going to introduce a rule – when we make a change we always make the change in a branch. When we make a branch we take a copy of the committed master branch, make a change and then merge back in regardless of how small the change will be.

Bob is the person working on the change and he will be adding more text and an image to the page so we will call the branch “bob-index.html-more-text-and-gitimage”. Naming branches in a conventional way really helps to know who made the branch and what the branch is for. Ideally branches are used for smaller changes that are rapidly saved and committed back to the main branch to stop conflicts which we will explain later.

We have to use dashes as branch names can not have spaces. You can use underscores or anything you like to break up the name of the branch.

The command to make the branch is git branch <branch name> so in this case it is

git branch bob-index.html-more-text-and-gitimage

We now have two versions of the repo: 1) main, 2) bob-index.html-more-text-and-gitimage. We can see what versions (branches) we have of the repo by typing git branch and you will get the following result.

  bob-index.html-more-text-and-image
* main

You will see there is a star or asterisk next to the main branch. This is shows the branch you are currently on and you can only be working on one branch at a time. To move to the new “bob” branch we type git checkout bob-index.html-more-text-and-gitimage. git checkout does what is says – it checkout (as you would check out a book in a library) the current repo status. This command changes the branch from main to the new one bob-index.html-more-text-and-gitimage and you can check this with the command git branch like we did before.

We are now on the bob branch – so what? Let’s change the index.html and see what’s different.

Create a new for images (mkdir img). Note that a new folder is not tracked by git until there is a file in there. Add the cat.png to the img folder and check the status of the branch with git status. This will show the img/ folder which hasn’t been added and the modified index.html.

On branch bob-index.html-more-text-and-image
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:   index.html

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

no changes added to commit (use "git add" and/or "git commit -a")

You can see above we are working on the bob branch. If we try and switch to the main branch we can’t as all changes would be lost (it’s the equivalent of going back to the start before the branch was created).

admin@yourcomputer gitPractice2 % git checkout main
error: Your local changes to the following files would be overwritten by checkout:
	index.html
Please commit your changes or stash them before you switch branches.
Aborting

To get back to the main branch we need to either commit or restore. Or .. stash. Stash is quick way to make a change to a working directory. We’ll come back to git stash as we need to complete one branch commit.

We have to commit the change through git commit -am “added history of git”. With the commit made to the repo we can move back to the main branch (git checkout main). git status shows us that there is nothing in either a working directory or staging so things are clean. We have made the change and everything is clean.

With the change made we can delete the branch which is git branch -d <branch name> so in this case git branch -d bob-index.html-more-text-and-image.

But we have a problem. When we try and delete the branch we hit a problem. “The branch <branch name> is not fully merged”.

admin@yourcomputer gitPractice2 % git  branch -d bob-index.html-more-text-and-image 
error: The branch 'bob-index.html-more-text-and-image' is not fully merged.
If you are sure you want to delete it, run 'git branch -D bob-index.html-more-text-and-image'.

admin@yourcomputer gitPractice2 % git status
On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   index.html

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

no changes added to commit (use "git add" and/or "git commit -a")

switch vs checkout of branch

HEAD -> main

git commands

git i