HackMD
git 補充內容
專案 to gitlab
個人專案除了放在本機端，同仁們目前有會放置在遠端數據庫(github)，下方將提供上述兩種狀況如何將檔案上傳至gitlab的方式。
1.github to gitlab–使用gitlab的import project功能
每個團隊都會有自己的遠端儲存庫，目前許多人都有再使用github，而AI組有自己建立的gitlab遠端伺服器，因此大家可以開始將放在各地的程式碼push到gitlab。
(1)登入gitlab後點選new project–>import project–>GitHub
(2)此處要求輸入Token。點擊紅框中Personal Access Token到GitHub生成Token
(3)點選Generate new token
(4)輸入名稱(Note)並勾選"repo"後，點擊最下方的Generate token
(5)將生成的token複製
(6)回步驟2頁面輸入token即可看到github上所有專案，選擇你需要的import
2.本機專案 to gitlab–使用指令上傳 or vscode
2.1 使用指令上傳
#Git global setup(設定global參數：名稱及信箱)
git config --global user.name "<c95xxx>"
git config --global user.email "<xxx@.gmail.com>"
#Push an existing folder(上傳本地資料夾)
#進入專案資料夾
cd existing_folder
#初始化專案資料夾(已經初始過可跳過此步驟)
git init
#連接遠端數據庫(remote)
git remote add origin https://gitlab.ai.icrd/c95sbh/123.git
#檔案納入版本控制
git add .
git commit -m "Initial commit"
#push到gitlab
git push -u origin master
2.2 使用vscode上傳
當使用vscode進入專案資料夾，點擊source control可選擇initialize repositiry或publish to github
1.點擊publish to github
確認允許登入github
點擊繼續
取得token
點擊左下區塊
輸入token
選擇private或public
選擇要上傳的檔案
完成上傳
2.點擊initialize repositiry初始化專案資料夾
點擊下方remote +號新增一個
輸入remote name(遠端數據庫對本地端的簡稱)
輸入URL
完成後點擊push(push按鈕在source control旁有三個小白點裡面可以找到)會發現出現以下問題，代表你尚未訂定我們master的上游分支，這樣上傳會出現問題！
接決方法為，點擊上傳publish repository設定
輸入帳號密碼
看到branch顯示已經連接後，就可以進行push了！
3.使用git –mirror方式上傳
3.1clone/clone –bare/clone –mirror差異
1.git clone (克隆)
0.0
2.git clone –bare (裸克隆)
0.0
3.1 git clone –mirror(鏡像)
0.0
3.2 clone/clone –bare/clone –mirror比較表
| git clone (克隆) | git clone –bare (裸克隆) | git clone –mirror(鏡像) | |
|---|---|---|---|
| 工作區 | 0 | x | x |
| 目錄名稱 | xxx | xxx.git | xxx.git |
| git fetch 上游版本 | x | x | 0 |
| 版本 | x | x | ^1.6.0 |
3.3 使用 Git Mirror 無痛轉移 Git Server
- 整包 clone 下來
git clone --mirror <URL>
- 到 gitlab 建一個空的 repo
- 進到專案資料夾，設定新的遠端 git repo 位置
cd <專案資料夾>
git remote set-url --push origin <URL>
- local 更新 remote branch，確認上傳分支並刪除其他分支(若不整理分支也可以，會自動將分支全數傳上遠端)
- 最後將整包 push 上去
git push --mirror
- 上傳完成後，可以在 Gitlab 上看到 repo 裡有以前在 Gitolite 的所有紀錄與東西囉。
3.2 裸儲存庫概念
「沒有工作目錄的純儲存庫」–>遠端共用儲存庫–>「裸儲存庫」(bare repository)
Git 屬於「分散式版本控管」，每個人都有一份完整的儲存庫(Repository)。也就是說，當你想要建立一個「工作目錄」時，必須先取得這個「裸儲存庫」的內容回來，這時你必須使用 git clone [REPO_URI] 指令「複製」(clone)一份回來才行，而透過 git clone 的過程，不但會自動建立工作目錄，還會直接把這個「裸儲存庫」完整的複製回來。這個複製的過程，就如同「完整備份」一樣，是把所有 Git 儲存庫中的所有版本紀錄、所有版本的檔案、…等等，所有資料全部複製回來。
請注意: 雖然「工作目錄」下的 .git 目錄也是一個「儲存庫」，不過工作目錄下的儲存庫還包含一些工作目錄下的索引資訊，紀錄著工作目錄下的狀態資訊，這些狀態資訊不會出現在 「共用儲存庫」裡面，這裡只有版本資訊而已 (也就是 Git 的物件資訊)。
分支合併選擇-merge vs cherry-pick
對於多分支的數據庫，我們時常需要將分支進行合併，此時可以分成兩種情況。
(1)當我們需要合併分支上所有的改動時，可採用之前所提到的 git merge方式
(2)當我們只需要合併分支上的某些改動時，可以採用 git cherry-pick
1.git merge
在先前的課程中已經有提過，這邊就不細談，有興趣的小夥伴請幫我前往連結中的分支操作章節查看，謝謝。
2.git cherry-pick
git cherry-pick的作用，就是將指定的提交(commit)應用於其他分支。
#將指定的提交(commitHash)，應用於當前分支
git cherry-pick <commitHash>
#若將commitHash改為分支名稱，應用的就會是該分支最新的提交
EX:
假設目前有兩個分支Master與Feature，下方的 a~g為各自的commitHash
a - b - c - d Master
\
e - f - g Feature
現在將提交f應用到master分支
#切換到 master 分支
git checkout master
# Cherry pick 操作
git cherry-pick f
完成操作後，可看到master尾巴多出了一個f
a - b - c - d - f Master
\
e - f - g Feature
若想一次提交多組，直接將需要提交的commitHash輸入即可
git cherry-pick <HashA> <HashB>
git flow VS github flow VS gitlab flow
1.git flow
緣由：
一個開發團隊可能有好幾個branch，但每個人對於分支的認知不同，造成每次commit到不同分支，大家也不知道合併要回到誰，若是都合併到master，一定會出大問題，故有了GitFlow去規範使用者。
目的：
主要是規範一個工作流程，使開發團隊遵守branch的commit規則，讓最後合併時不容易出問題，並且簡化整個流程圖，讓開發團隊不必自己研發一個新的流程。
Git flow的優點是分支狀態系統化、清晰可控，缺點是相對複雜，需要頻繁切換分支，而且不利於CI/CD。如果在版本快速迭代的專案中，是幾乎用不到Hotfix 和 Release 分支的，因為合併到master後如果有bug就直接修復且發布下個版本了，如果還使用這兩個分支，需要合併回develop 和master分支，但實際上開發者很常忘記合併回這兩個主分支。
2.github flow
緣由：
因為Git flow太過於複雜，故又推出了GitHub flow去簡化流程。由管理者來負責做分支的合併，其餘的開發者只需專心開發branch就好，但是開發者在commit時，務必要撰寫清楚，讓大家知道你在做甚麼，且管理者才知道如何合併。
流程：
- 創建分支 (Create a branch) (fork也可以)
- 提交修改 (Add commits)
- 開啟 PR (Open a Pull Request)
- 代碼審核 (Discuss and review your code)
- 部屬 (Deploy)，先測試是否有bug，測試完畢後再進行下一步
- 合併 (Merge)
GitHub flow則適合項目是”持續發布”類型，比Git flow簡單，適合CD/CI，缺點由於master為最新代碼，但是準發布版本不一定是用最新代碼，或是有固定時間才發布更新的項目，就會有影響(例如:發布ios APP時會審核master時，但審核期間如果有新版本推上會造成審核延遲)。如果只有一個master主分支就會不夠用。所以還得另外再建一個新分支來維護。所以又發展出了Gitlab flow。
3.gitlab flow
緣由：
想改善Github flow的弱點，多設定一支發布分支，以此來改善github flow較難管理上膽問題的弱點，但依舊保持簡單的優勢。
Gitlab Flow的最主要原則為上游優先(upstream first)，只存在一個分支master，其他的branch都是下游，當下游出問題時，需要先開個分支，修完bug後合併回Master，再從master往出問題的下游合併，此做法是擔心開發者在下游修完bug，就忘了合併回master，造成後續的分支又遇到同樣的bug。
是 Git flow 與 Github flow 的綜合。結合了兩者的優點，有開發環境上的彈性又有單一主分支的方便。master的分支不夠，於是增加了一個 prodution 分支，專門用來發布版本。
語意化版本
語意化版本 2.0.0
版本格式：主版號.次版號.修訂號，版號遞增規則如下：
主版號：當你做了不相容的 API 修改，
次版號：當你做了向下相容的功能性新增，
修訂號：當你做了向下相容的問題修正。
先行版號及版本編譯資訊可以加到「主版號.次版號.修訂號」的後面，作為延伸。
如何建立標籤
