# git contribution

* [使用 git pull --rebase 處理遠端提交](https://awdr74100.github.io/2020-05-04-git-rebase/)
* [開發完成推向遠端分支 - git rebase、git pull –rebase](https://hackmd.io/@romazing/rkKvskBsn)
* [Git Cherry-pick 實戰：最佳實踐與應用場景](https://notes.boshkuo.com/docs/DevTools/Git/git-cherry-pick)

inspire

* message queue

## strict workflow

核心就是 resolve upstream main conflict

### contributer

* upstream: repo of reviewer
* origin: repo of contributer own

when want to implement a new feature

---
title: git contributer
---
flowchart TD;
	n1["git checkout main"]
	n2["git fetch upstream main"]
	n2 --> n1
	n3["git merge upstream/main"]
	n1 --> n3
	n4["git checkout -b feat/XXX"]
	n3 --> n4
	n4 --> n5["Do your feature"]
	n5["Do your feature then commit"]
	n6["create WIP PR, from your feat/XXX branch to upstream main"]
	n9["git rebase --continue"]
    n8["ask review to merge, then modification (always no conflict to upstream main)"]
	n7["git pull upstream main --rebase # never merge!!!"]
	n10["git push origin # push feat/XXX to your own remote"]
	n6 --> n8
	n5 --> n7
	n9 --> n10
	n10 --> n6
	n11["git cherry-pick $(git rev-parse upstream/main) --no-commit"]
	n12["git commit"]
	n5 --> n11
	n13["resolve"]
	n14["resolve"]
	n11 --> n13
	n13 --> n12
	n7 --> n14
	n12 --> n10
	n14 --> n9
    n8--"repeat cycle"-->n7
    %%n8-->n11

* 可以在 `git pull upstream main --rebase` 之前先下 `git branch PR/feat/XXX` 避免操作 rebase 錯誤後，無法復原。
* rebase 會 移動 commits 的起點和結束點
* cherry-pick 不會移動起點，只會改終點。
* cherry-pick 會比 rebase 簡單，但是 PR 需要時間審核，所以同時一定會需要 branch serveral branch。保留起點了話，在 merge 後就容易有多條並行的線圖。
* 並且由於change 是 copy 到 work branch，有變更的檔案會越來越多，甚至影響到正常審核。
* **建議優先使用 rebase**

### reviewer

* origin: repo of reviewer own

---
title: git reviewer
---
flowchart TD;
	n1["when non-conflict PR existed"]
	n2["git fetch specific_remote feat/XXX"]
	n1 --> n2
	n2 --> n3["git reset --hard specific_remote/feat/XXX"]
	n3 --> n4["run local build, checkout no bug"]
	n3
	n5["run app, checkout no bug"]
	n4["run local build, run unit test"] --> n5
	n5 --> n6["click merge button on git web UI"]
	n6 --> n7["git fetch origin main"]

## why

* 想要 敏捷、CI/CD
* 這是主要因素，以前可能 1~2 weeks merge 一次。現在希望盡快讓最新的修改上線，自然就要標準化PR的方式，降低 merge的阻力。
* 讓 reviewer solve conflict 會導致 reviewer 變 bottleneck。
* 必須要讓 contributer solve
* The most straight forward result is **scale** of the team. If reviewer have to solve conflicts in PR, The team is hard to become more than 5 people usually 3 only. On the other hand, strict workflow can scale whole team to about 15.
* 不想要有 branch of branch graph，會難以理解。
* rebase, cherry pick
* 任何 merge 類 行為都會導致龐大的graph

## toward automatic team

* strict workflow above
* conflict issue has well-defined method to solve
* unit test
* ensure new code/ resolve conflict doesn't break previous feature.
* This is especially important at multi-contributer repo to prevent from merge breaking existed implement.
* completed CI/CD tool
* prevent repeated work to prevent from reviewer become bottleneck
* The final goal is keep whole code review work on web platform.
* switching between several PR and build locally is time consuming
* main to deploy
* minimize time between main to release, lower down reviwer burden.
* build and run each PR unittest
* build and run each commit take time and will pause reviewer work.
* And contributer know if there is basic mistake.
* build and run app preview of PR
* code quality tool (optional)
* LLM code review tool

Reviewers only need to review source code now, they should ensure contributer follow design(code arch).