Introduction to Git

The problem(s)…

• "Where did I save that script again..?"
• "Which version of that are you using?"
• "Did you end up solving that bug we found the other day?"
• "Good that you fixed that, can you send me the updated version?"
• "I added this feature, can you integrate it in the code?"
• "I SWEAR IT WAS WORKING YESTERDAY, I DON'T KNOW WHAT CHANGED"

Manual backups can help, but…

Source: https://phdcomics.com/comics/archive.php?comicid=1531
©️ Jorge Cham

… the real™ solution

• Version control systems (VCS)!
  • Keep everything you need in a single "bucket" (repository)
  • Make sure everyone has access to the latest developments
  • Keep track of the history of a document/software
  • Sustainable collaborative workflows
• Different flavours:
  • Centralised: Concurrent versions system (CVS), Subversion (SVN), Perforce, …
  • Distributed: Git, Mercurial, Bazaar, …

Keep track of the history of the code

Centralised vs distributed VCSs

• Centralised:
  • One main remote repo that stores every version of the code
  • Client-server architecture
  • Every developer has only a local snapshot of the latest version
  • Pros: work really well with binary files, easier to learn
  • Cons: single point of failure, client-server communication can slow down development, only one person can work on a piece of code at a time

Centralised vs distributed VCSs

• Distributed:
  • Every peer has the whole history tree cloned on their device
  • Possible to work offline, servers only stores the difference between versions
  • Possibility to implement strong workflows and code-checking procedures
  • Pros: More resilient (everyone has a backup), flexible branching (tested locally), quick development cycles
  • Cons: steeper learning curve, suboptimal for large binary files

Git structure and workflow

%%{init: {'theme': 'default', 'gitGraph': {'rotateCommitLabel': true, 'useMaxWidth': false, 'showCommitLabel': false, 'nodeLabel': {'width':100, 'height': 30, 'x': 0, 'y': -10} }, }}%%

---
title: Lesson development
---
gitGraph
   commit
   commit
   branch julia_notebook
   checkout julia_notebook
   commit
   commit
	 commit type: REVERSE
	 commit
	 checkout main
   branch python_notebook
	 checkout python_notebook
	 commit
     checkout main
	 commit
     checkout python_notebook
     commit
	 checkout main
   merge python_notebook
   commit
   commit

• The history of a repo is a directed acyclic graph (DAG)
• Each arrow is a branch
  • Branches can be used as sandboxes to modify/develop things without affecting the main version
• Each dot is a commit, i.e. a saved snapshot of your repo
  • Each commit should include a message (e.g. "fixed this bug")
• Branches can then be merged back into the main path (blue)

Git structure and workflow - Collaboration

• Remember: Git is decentralised!
  • Every change you make is local!
  • This means that changes have to be pushed to the remote repo (e.g. GitHub)
  • It also means that the latest changes have to be pulled
  • Very easy to keep up with people's work: you just pull from the remote origin :)
  • During merges/pulls, code reviews and discussion, as well as tests, can be performed

Logging in Git

Project management features

• Couple of platforms based on git: GitHub, GitLab
• Both have features such as:
  • access levels: for creating groups of maintainers / developers / reviewers + their code projects
  • planning: organize issues, pull-requests, milestones in a Kanban board
  • CI/CD: automatise workflows, deploy
• RISE runs their own GitLab!
  • Join the GitLab team
  • After 15 minutes, login to https://git.ri.se

Let's give a look to the RISE Gitlab!