mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 13:24:05 -06:00
120 lines
3.2 KiB
Markdown
120 lines
3.2 KiB
Markdown
---
|
|
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
|
|
|
|
[[cheatsheets/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
|
|
```
|
|
|
|
- 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
|