Introduction

• Version control is coding best practice
• Lets us keep a “ground truth” copy of our code.
• Supports collaborative development

Git

• Version control system written by Linus Torvalds
• Distributed Version Control
• Industry Standard

GitHub

• Cloud based fronted for Git
• Repository Storage and Administration

GitHub != Git

• Synonymous, but not the same
  • Git == Version Control System
  • GitHub == Cloud based management of repos

Alternatives to GitHub

• Bitbucket
• GitLabs
• Self Hosted (ie GOGS)

Alternatives to Git

• Subversion
• Mercurial
• Bazaar

Question

• Do you have a preferred Version Control System?
• Do you have a preferred front end?

Why Version Control?

• Structured way to work with files while storing state
• Keep track of changes, versions and features
• Enable development without breaking our Release Version

Why Version Control?

• Important_Document.docx
• Important_Document_Final.docx
• Important_Document_Final_3rd_April_DG.docx

Why Version Control

• We only have one current version “Final” version of the document
  • Variations can be kept in “Branches”
  • History is managed by the VC

Version Control Benefits

• Complete History of changes to files
• Branch and Merge Support concurrency
• Trace-ability.

Some Downsides to version control

• Can be public:
  • Need to take into account security factors

Coventry GitHub Instance

• We have our own instance of GitHub at the university.
  • github.coventry.ac.uk

Module Materials:

• Lectures
  • https://github.coventry.ac.uk/aa9863/7148CEM
• Labs
  • https://github.coventry.ac.uk/aa9863/7148_Labs_2223

Coursework

• Coursework is development of embedded system
  • Software development.
• We can use VC to share the source code.

Download the Lab Examples

• Lab examples are read only:
  • First we need to get the examples locally
  • clone a copy of the repository.

Clone

Clone

dang@danglaptop /tmp$ git clone git@github.coventry.ac.uk:aa9863/7148_Labs_2223.git                                                                                     1 ↵  
Cloning into '7148_Labs_2223'...
remote: Enumerating objects: 18, done.
remote: Counting objects: 100% (18/18), done.
remote: Compressing objects: 100% (11/11), done.
Receiving objects: 100% (18/18), done.
remote: Total 18 (delta 0), reused 18 (delta 0), pack-reused 0

Updating the Examples

• New code will be released for each session
  • We need to update
• For this we use a pull

Git Pull

dang@danglaptop /tmp/7148_Labs_2223$ git pull                                                                                                                           main 
Already up to date.

Creating our own workspace

• We will also want something to work in.
• Lets create two repositories
  • One for Lab work
  • One for Coursework

Creating a coursework repository

• First we create a new repo using GitHub Web interface
• We can then clone this to our local machine to give us a workspace
• Important:
  • Repo should be PRIVATE
  • Add me as collaborator.

Creating a Repo

Creating a new Repo

Adding Colaborator

Cloning to local machine

• Two options here
  1. Use command line
  2. Use VS Code

Cloning to local machine

Using VS Code

• Ensure we have the Git Branches extension installed

Using VS Code

• Select Clone
• Add Repository URL

Adding a File

• Lets Create a README.md
  • Used to Explain what project is about

Committing Changes

• Once we are happy with our content, we need to commit.
  • Click the Plus to Stage our changes
• This will save the changes to the version control history

Staging

• Staging tells GitHub what should be in ou commit
• We can stage files with the + Icon.

Staging Changes

Staging Changes

Committing

• Committing will store our currently staged changes
• Take a “Snapshot” of the state of our repo

Commit Best Practices

• Commit Often
  • Its “free”
• I like to commit after every block of functionality has been done

Commit best practices

• Try to group relevant files together
  • If you make changes to something unrelated to the work, use a separate commit
• Use a useful Commit message

Pushing

• Our changes are stored locally.
• Need to push to the central repository

Pushing

• Either click Sync
• Or select push from the options menu

Workflow Summary

Advanced Workflows

• Working in Main is Bad
  • Changes the “release” version of our code
  • Issues with multiple people working and conflicts

Branches

• Branches are the answer
  • A Copy of the repo we can work in
  • All changes are contained in the branch

Branches Workflow

• I like the “feature branch” approach
  • Create a new branch for each feature / bugfix
• Main only contains “Production” code

Creating a Branch (CMD)

• We can do this is Command line

Creating a branch (VS Code)

• Click the Branch Icon at the bottom
• Follow Prompts

Creating a branch VS

Working in our branch

• Same approach as before
  • Work
  • Stage
  • Commit

Working In our Branch

• When we commit, main is not changed
• We can see status of branches using UI

Working in a branch

Branching Workflow

Changing Branches

• Its possible we are working on multiple branches at the same time:
  • We can use git checkout

Pull Requests and Merges

• When we are finished with the branch, we can commit to main
• For this we use Pull Requests

Pull Requests

• Puts all changes into one logical block
• Offers Code review features
• Great for team working

Pull Requests

Getting Used to Git

• Clone the Lab tasks
• Create a repo for your version of lab work
• Try the Branch -> Commit -> Pull Request workflow.

Summary of Today

• Getting to know you
• Introducing the Module
• Inroducting the Tools we will use

Tomorrow

• Overview of C/C++
• Doing more with platform IO