A place where you can store your code, your files, and each file’s revision history.
Contains a .git folder at the root which does all the git magic behind the scenes.
Creating a git repository
Navigate to a folder you want to work in, and create a new folder to contain your repository:
$ cd your_dir$ mkdir intro-repo$ cd intro-repo
Then initialise the folder
$ git init -b main
.git
A hidden .git folder has been created in your folder. This contains everything Git needs to work.
What is a Git commit?
You can think of a commit as a snapshot of your work at a particular time
You can navigate between commits easily with git
This allows you to switch easily between different versions of your work
When you commit, rather than saving all the files in a project every time, git is efficient and only stores the files which have been changed between the previous commit and your current one
The commit also stores a reference to its parent commit
Committing is a three part process:
Modify: change the file in your working tree, i.e., go in and edit the file as usual
Stage: Tell git that you would like this file to be included in your next commit
Commit: Tell git to take a snapshot of the files you staged
At each step in the process, the file is stored in a different area:
Git States
git has four main states that your files can be in:
Untracked: You’ve created a new file and not told git to keep track of it.
Modified: You’ve changed a file that git already has a record of, but have not told git to include these changes in your next commit. We say these files are in the working tree.
Staged: You’ve told git to include the file next time you do a commit. We say these files are in the staging area.
Committed: The file is saved in it’s present state in the most recent commit.
Create an untracked file:
Create an untracked file:
Create a new file in your repository.
$ touch new.txt$ vim new.txt
Lets check what git can see…
$ git status
git status
$ git statusOn branch mainNo commits yetUntracked files:(use"git add <file>..." to include in what will be committed)new.txtnothing added to commit but untracked files present (use"git add" to track)
git status
Highlights your working branch -> main Reports commit status -> none yet Highlights untracked files -> new.txt Proposes adding these to git with git add
Add the untracked file to the staging area:
git add
$ git statusOn branch mainNo commits yetChanges to be committed:(use"git rm --cached <file>..." to unstage)new file: new.txt
git add
Moves file(s) into “Staging area” ready for commit
Committing your changes:
Committing your changes:
Commit your file to the local git repo
$ git commit -m"Commit message"
git commit: tells git you want to commit
-m "Commit message": adds a human-readable description to the log of this commit. This is important as it tells you and others what the commit intent is.
Writing meaningful commit message
There are many conventions and good practices to write good commit messages. Based on scope of the project and other factors particular conventions are chosen.
Keeps work-in-progress code out of the main branch.
Can regularly commit smaller changes without worry.
Tip
Keep branches short-lived. Long branches with large changes become harder and harder to merge.
Ways of working with a remote repository
A remote repository is one stored in the cloud. We will be using GitHub to do this today.
There are two different ways to copy a remote repository so that you can work on it locally:
clone: This makes a copy locally which is linked to the remote version. Your local branches can be synced to branches in the original.
fork: This makes another separate version of the repo remotely that you own. Once you have forked a repo remotely, you can then clone it to your local machine. You can still contribute to the original repository through a pull request.
To clone or to fork?
Use a fork when:
The owner of the repo is not someone you are actively collaborating with
You want to take the development of the code in a different direction from the original owner of the repo
You want full ownership over your version of the codebase
You want complete control over other’s contributions to the codebase
You do not want the main branch to receive updates from those editing the original repo
Or you do not have permission to push branches directly to the original repo
Use a clone when:
You are collaborating directly and actively with the owner of the repo (e.g. it is your research team, or you)
OR all of the following is true:
It is owned by someone else and you are happy not to have ownership of the codebase
You have permission to push branches up to the repo
You want easy access to the latest changes made by others to the central repository
You want the main branch in the repo to be updated and edited by others working on the project
Working with remote repositories
Collaborative git with GitHub
Warning
You must have already created a GitHub account before you can do these exercises
You can work through the following exercise in your own time. If you do this in the Miniprojects slot on Thursday we will be around to answer questions.
Forking
Reminder:
Forking creates another separate version of the repo remotely that you own.
Once you have forked a repo remotely, you can then clone it to your local machine. You can still contribute to the original repository through a pull request.
Forking Exercise
Use the practice repo we used for the cloning exercise and follow the steps outlined in the next slides to fork the repository, clone the fork and contribute back to the original repository.
