---
title: "git"
tags: 
- cosc202
---

- Git is a tool to track changes to sets of file
- It is the most commonly used [[notes/version-control-system]]

## 1 Team git protocols

you can develop a team protocol for Git use

e.g.,

- agree to commit often
- know what branches are being used and why
- consider pair programming / live sharing
- try not to touch lots of files without signalling why
- agree who's going to edit files that maight not auto merge

## 2 web based repo access control

- owner of repo chooses who can push to project
	- maintainer -> cant remove data
	- developer -> cant manage team
	- reporter -> cant change codebase
	- guest -> can view

### 2.1 open source collaboration

you want contributions from everyone

but you dont want to manage user-level control

-> pull/merge requests

unknown users can fork then add a feature/bug then do a merge request which can be reviewed

## 3 git repos

[[notes/git-cheat-sheet|Repositories]] maintain code history
can be conceptualised as a graph

```mermaid
	graph RL
	A[HEAD]-->1[MASTER]-->B((ab348b))-->C((hf33h3))
	C-->D((3hh39h))
	C-.Merge.->E((n3383b))
	3[Branch]-->E
	D-->H((kfj383))
	E-->G((gj4jf4))
	G-->H
	H-->I((fjfj39))
	I-->2[Inital Commit]	
```
```mermaid
	gitGraph:
	checkout master
	commit
	commit
	branch newbranch
	checkout newbranch
	commit
	commit
	checkout master
	commit
	merge newbranch
	commit
	commit
```

![[Pasted image 20220306103955.png|300]]

- nodes are commits -> immutable snapshots of the tracked files
- edges record how nodes emerged over time
	- arrows can be read as "is derived from"

git is a [[notes/version-control-system#4 3 Distributed Centralised]]

- every team members has their own local copy of the repo
- git repos are often syned with a server: github, gitlab,etc

## 4 levels of complexity/Abstraction

```mermaid
	graph TD
	w(github gitlab from web browser)-->b(graphical ide's e.g., vscode)-->c(command line git)-->d(low level git plumbing commands)-->e(direct manipulation of records within repo's .git directory)
	
```

## 5 Limitations/pain points

- not designed for broad usability
	- bottom up design stems from its implementaion,
	- rather than top down design from user interface
	- thus, command naming and syntax can be unintuitive
- git is not suited to handling large data files
	- git scans whole files to generate hash codes
	- can use git lfs (large file support) to get around this
- flexibility of git can lead to high cognitive load
	- e.g., many ways to get others' commits to your repo
- binary files e.g., JPEG images are treated as whole
	- no differencing, no content merging
- some text files may not have stable line structure
	- e.g., XML data can be reordered wihout changing so:
		- git can auto merge when this is destructive
		- git may get confused and force you to merge
	- e.g., node package-lock.json
	- you can turn of auto-merge if you are working with files that may be problematic

## 6 advantages

- git repos' data structures are well designed
	- clear in structure yet flexible and efficient
- few dependencies
	- widely available
	- free and open source
- community support around use of git is great
	- eforts to get researches to use version control;
	- github helped open source software flourish by making it easy for citizens to contribute to projects