git 補充內容

• git 補充內容
  • 專案 to gitlab
    • 1.github to gitlab–使用gitlab的import project功能
    • 2.本機專案 to gitlab–使用指令上傳 or vscode
    • 3.使用git –mirror方式上傳
  • 分支合併選擇-merge vs cherry-pick
    • 1.git merge
    • 2.git cherry-pick
  • git flow VS github flow VS gitlab flow
    • 1.git flow
    • 2.github flow
    • 3.gitlab flow
  • 語意化版本
  • 參考資料

專案 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

1. 整包 clone 下來

git clone --mirror <URL>

2. 到 gitlab 建一個空的 repo
3. 進到專案資料夾，設定新的遠端 git repo 位置

cd <專案資料夾>
git remote set-url --push origin <URL>

4. local 更新 remote branch，確認上傳分支並刪除其他分支(若不整理分支也可以，會自動將分支全數傳上遠端)
5. 最後將整包 push 上去

git push --mirror

5. 上傳完成後，可以在 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時，務必要撰寫清楚，讓大家知道你在做甚麼，且管理者才知道如何合併。

流程：

1. 創建分支 (Create a branch) (fork也可以)
2. 提交修改 (Add commits)
3. 開啟 PR (Open a Pull Request)
4. 代碼審核 (Discuss and review your code)
5. 部屬 (Deploy)，先測試是否有bug，測試完畢後再進行下一步
6. 合併 (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 修改，
次版號：當你做了向下相容的功能性新增，
修訂號：當你做了向下相容的問題修正。
先行版號及版本編譯資訊可以加到「主版號.次版號.修訂號」的後面，作為延伸。
如何建立標籤

參考資料

1. 30 天精通 Git 版本控管 (03)：建立儲存庫
2. git 仓库迁移的两种方法
3. Git上的三種工作流程
4. git flow 實戰經驗談 part1 - 別再讓 gitflow 拖累團隊的開發速度
5. cherry