COMP30023 Week 02 – git
School of Computing and Information Systems
COMP30023: Computer Systems
Copyright By PowCoder代写 加微信 powcoder
Practical Week 2
1 Introduction
Git is a distributed version control system originally developed by Linus Torvalds to maintain Linux kernel
code. It is now widely used in all kinds of projects to track changes in files and enable collaboration
among developers. Consequently, using version control in software engineering projects is a necessary
practice for collaboration and to maintain backups of the project and should not be considered optional.
This lab will serve as a brief introduction to Git so that you can start using it to manage code in your
own projects.
2 COMP30023 Gitlab Access
Please first complete the Gitlab Access assignment, to gain access to your assignment/project submission
repositories. Everyone (including those who enrolled in previous iterations of COMP30023)
must complete this assignment. Do not wait for the automated program to grant you access (it
runs half-hourly and only supplies access to project repositories). Instead, you should continue with the
activities below with your https://gitlab.eng.unimelb.edu.au account.
3 Installing new packages
While Ubuntu Server (the Linux distribution that we’re using) comes with some standard packages1 (e.g.
coreutils2), not all the commands and tools that we’re going to use in this subject is preinstalled.
We can use Ubuntu’s default package manager to install new software.
Install new package(s) with $ sudo apt install
Let’s install gcc (or clang, if you prefer), make, and git, which will be required to complete the projects.
Confirm correct installation of git and the gcc compiler.
Command: $ gcc –version , $ git –version
4 Introducing Yourself to Git
Before we start using Git, we need to setup our name and email. Note that this is just for identification
purposes, and not to log in to any system. This process will need to be repeated on each user account
on which you want to use git.
Command: $ git config –global user.name “Your Name”
Command: $ git config –global user.email 4
Now that Git knows who we are, let’s create our first repository.
1http://releases.ubuntu.com/20.04/ubuntu-20.04.2.0-desktop-amd64.manifest
2https://en.wikipedia.org/wiki/List_of_GNU_Core_Utilities_commands
3You may need to run $ sudo apt update first
4The –global option means that Git will use these values for every Git project the current user creates. The values
are written to ~/.gitconfig
https://gitlab.eng.unimelb.edu.au
http://releases.ubuntu.com/20.04/ubuntu-20.04.2.0-desktop-amd64.manifest
https://en.wikipedia.org/wiki/List_of_GNU_Core_Utilities_commands
5 Creating a Git Project
Git projects are more commonly known as Git repositories. Let’s initialise a repository.
1. Create a new directory. Let’s call it git-repo-1 .
2. Navigate into the newly created directory.
3. Initialise a repository in this directory. Command: $ git init –initial-branch=main
If you get the error unknown option `initial-branch=main` , you have an older version of git.
Run $ git init now and $ git branch -M main after making your first commit (Section 7).
This will create a new (hidden)5 directory named .git in the git-repo-1 directory. This
directory will contain all version information related to this repository.
Note: Do not initialise a git repository at ~ .
If you did this accidentally, use cd ~&& mv .git/ git.bak
Sample solutions will be released at the end of the week.
Ask your classnames and demonstrator for help during practical classes.
6 Adding Files to Git
A file can exist in three stages in a Git repository: Working, Staging and Commit6.
• Any changes not explicitly added to the Staging area reside in the Working Directory.
• Changes can be added to the Staging Area (also known as Index) using the git add command.
This marks the changes that should go into the next commit
• The git commit command adds the marked changes from the step above to the (local) repository.
Figure 17 shows the flow of operations:
Figure 1: Flow of operations
Let’s see this in practice:
1. Create an empty file named test.c with the touch command.
Command: $ touch test.c
2. This file is now in the working directory and untracked by Git. Run the git status command
to see this.
Command: $ git status
5You can use the command ls -a to view the directory.
6You can also stage parts of a file, which is unique to Git and a main reason for the intermediate Staging step
7Source: https://git-scm.com/about/staging-area
https://git-scm.com/about/staging-area
3. Add some content to the file to make it compilable, using nano , vim , echo etc.
e.g. the line void main(){} in test.c .
Brief instructions for nano :
$ nano test.c , type in text, ctrl-x, letter y, enter key.
Brief instructions for vim :
$ vim test.c , letter i to enter insert mode, type in text, escape key to exit insert mode and back
to normal mode, :x, Enter to save.
4. Add this file to the staging area.
Command: $ git add test.c
5. View the status of the repository now using the git status command again. Notice that the
test.c file is now listed under ‘Changes to be committed’.
6. If you have modified multiple files and want to add all of them to the staging area at once, you can
use the git add . command.
7 Committing Changes
Now that we have added our changes to the staging area (i.e. marked the changes we want to commit),
let’s commit the changes.
Committing the changes stores a snapshot of the current state of the files. This allows you to roll back
to this version if needed in the future. Note that this snapshot is stored locally on your machine.
1. Command: $ git commit -m “Created test.c with main()”
Every commit needs to be accompanied by a commit message, which is what we specified using
the -m parameter.
2. Inspect the current status of the repository using git status .
You can also combine the add and commit steps in one operation using the
git commit –all -m “commit message” command.
Note that this combined operation only commits changes to files added earlier, and does not commit
new files.
8 .gitignore
Now that we have made our first commit, let’s compile test.c with gcc.
1. Write a Makefile to compile test.c with gcc to an executable named test .
Discuss with your classnames, demonstrator if you have forgotten how to do so. Solutions will be
released at the end of the week.
2. Execute $ make .
3. Verify that compilation was successful (i.e. does test exist? is test executable?).
4. Execute $ git status again. Both Makefile and test should be unstaged at this point.
5. We shouldn’t stage and commit test, as it is a binary file which is machine architecture depen-
dent and can be reproduced any time that we run make. By committing it, we are bloating our
repositories with different versions of test. When repositories are then pushed to servers, all of
these rubbish files will have to be uploaded!
While it is possible to selectively choose files to stage and commit them (e.g. $ git add Makefile ),
the convenience of using $ git add . is lost. This is the purpose of the .gitignore file, which
can be used to specify (in separate lines) the file(s) and director(ies) which should be ignored by git.
Let’s create a .gitignore file, containing a single line:
This tells git to ignore files named test.
We can also use wildcards, e.g. *.o to ignore all .o files.
6. Check $ git status again. Once you’re happy, stage Makefile and .gitignore simultane-
ously and commit the changes, giving the commit an appropriate message.
7. Use the $ git log command to view the history of commits you have made.
Note: you are expected to follow good version control practices (sensible commit messages, no useless
executables etc.) for project repositories. More on this in the project specifications.
9 Setting up GitLab
It is common practice in teams to have a Git server that everyone push es their code to.
Github and Gitlab are examples of publicly-available hosting services. We will be using Gitlab, open
source software that is hosted on the servers of the Faculty of Engineering and IT.
Login to https://gitlab.eng.unimelb.edu.au.
Click ‘Create a Project’ and create a project named comp30023-practical-2 .
Set the visibility level to ‘Private’ and deselect “Initialize repository with a README”.
10 Pushing Changes
Note that every git operation up to now has been done locally. That is, our changes to the files have
not been sent to a remote server.
1. For this, we need to tell Git which external repository (remote) we want to link our local repository
$ git remote add origin https://gitlab.eng.unimelb.edu.au/〈username〉/comp30023-practical-2.git 8
You can check the URLs using git remote -v and where necessary, amend it using
git remote set-url origin
2. Push your changes to the server by using the git push command.
Command: $ git push -u origin main
After this first push you can push changes by simply using the command git push
You do not need to push after every commit.
It is appropriate to push after every major change (e.g. a new feature, a bug fix, some refactoring etc.)
11 Cloning
It is common to join a team with an ongoing project which does source code management using Git. We
use the git clone command to get a copy of existing code stored on an external Git server.
8We are setting an alias named origin to the URL so that we don’t have to type the entire remote URL each time we
https://gitlab.eng.unimelb.edu.au
1. Run this command from a directory outside the Git repository we have been working in
$ git clone https://gitlab.eng.unimelb.edu.au/〈username〉/comp30023-practical-2.git
2. Note that a new directory has been created with the name comp30023-practical-2 . Browse
to this directory, view files. Use the git status and git log commands to note that the full
history of the repository has been downloaded.
12 Branches
Git allows you to organise code in branches.9 For example, you might create a new branch for a new
feature of your application. You can then keep continued development on the core of the application
(e.g. bug fixes) separate from the new feature development.
Note: The use of gitk , if available, can be very helpful when dealing with multiple branches.
1. When initialising the repository, we specified the default branch to be named ‘main’ (to be consis-
tent with Gitlab). Use the git branch command to list the current branches.
Command: $ git branch
The currently active branch is shown with an asterisk.
2. The most common way to create a new branch in Git is to create a new branch and switch to it in
the same command10. Let’s create a new branch named ‘new-feature’.
Command: $ git checkout -b new-feature or $ git switch -c new-feature
3. Run the git branch command again. Notice the newly created branch is currently active.
4. Create a new file, add it to the staging area and commit it using the commands you have learnt.
5. Switch back to the main branch.
Command: $ git checkout main or $ git switch main
6. List the files (including hidden ones) in the directory using the ls command. Notice that we only
see .gitignore , Makefile , test and test.c . This is because the change we made was in
the other branch named ‘new-feature’.
When we have finished developing the feature, we will want to bring those changes into the main
branch. We do that using the git merge command
Command: $ git merge new-feature
This command brings in the changes in the ‘new-feature’ branch to the currently active branch.
For this reason it is important to be sure of what the current branch is.
7. List the files in the directory using ls . Notice that the file you created in the new-feature branch
is now available in the main branch.
8. This merge was an example of a merge without ‘merge-conflicts’. A merge-conflict occurs when the
same line has changed in both branches.
Information on resolving merge-conflicts, and on the idea of branches as pointers to commits is avail-
able at https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
9Git’s lightweight branching capabilities are often called its ‘killer feature’
10This is a shorthand for the commands git branch and git checkout
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
Git is a Version Control System. It allows the labelling of different versions of code (e.g. like in software
versions such as Microsoft Word 16.0.8730.2175)
You can add a tag to a commit using
$ git tag -a v0.15 -m “Release version 15”
The -a parameter is the tag label or ‘annotation’. The -m argument allows the addition a message to
Tags in Git need to be explicitly pushed. You can push a single tag using $ git push origin v0.15 ,
or all created tags using $ git push –tags .
14 Resources
Git is complex and feature-rich; we have only just scratched the surface of its capabilities in this short
hour. The resources below will help you learn more.
• https://git-scm.com/book/en/v2
A canonical reference. Authoritative and extremely well written.
• http://eagain.net/articles/git-for-computer-scientists/
In the author’s own words: ‘Quick introduction to git internals for people who are not scared by
words like Directed Acyclic Graph.’
• https://www.youtube.com/watch?v=4XpnKHJAok8
Straight from the horse’s mouth. Linus Torvalds on Git.
• http://gitolite.com/uses-of-index.html
Why the index/staging area is so useful
Git is very widely used, which means there is an abundance of resources on the Internet. Happy learning!
https://git-scm.com/book/en/v2
http://eagain.net/articles/git-for-computer-scientists/
http://gitolite.com/uses-of-index.html
Introduction
COMP30023 Gitlab Access
Installing new packages
Introducing Yourself to Git
Creating a Git Project
Adding Files to Git
Committing Changes
.gitignore
Setting up GitLab
Pushing Changes
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com