quartz/content/notes/git.md

title	tags
git	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

cheatsheets/git-cheat-sheet maintain code history can be conceptualised as a graph

	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]	

	gitGraph:
	checkout master
	commit
	commit
	branch newbranch
	checkout newbranch
	commit
	commit
	checkout master
	commit
	merge newbranch
	commit
	commit

!Pasted image 20220306103955.png

• 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

	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