mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 05:14:06 -06:00
130 lines
3.3 KiB
Markdown
130 lines
3.3 KiB
Markdown
---
|
|
title: Git
|
|
draft: true
|
|
sr-due: 2022-04-12
|
|
sr-interval: 29
|
|
sr-ease: 270
|
|
---
|
|
|
|
tags: #review
|
|
|
|
---
|
|
# Git
|
|
Git is a tool to track changes to sets of files
|
|
It is the most used [[Version Control Systems|VCS]
|
|
|
|
## 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
|
|
|
|
## 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
|
|
|
|
### 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
|
|
|
|
## git repos
|
|
[Repositories](out/notes/git-cheat-sheet.md#^3b3a5d) 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 [Decentralised and Centralised VCS](out/notes/version-control-systems.md#^98d838)
|
|
- every team members has their own local copy of the repo
|
|
- git repos are often syned with a server: github, gitlab,etc
|
|
|
|
## 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)
|
|
|
|
```
|
|
|
|
## 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
|
|
|
|
## 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|