# git 補充內容
[TOC]

## 專案 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
在先前的課程中已經有提過，這邊就不細談，有興趣的小夥伴請幫我前往[連結](https://hackmd.io/c62y53DfS5ms1rzSyXbuTg#Git%E2%80%93%E5%88%86%E6%94%AF%E6%93%8D%E4%BD%9C)中的==分支操作==章節查看，謝謝。
### 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](https://semver.org/lang/zh-TW/#%E8%90%AC%E4%B8%80%E4%B8%8D%E5%B0%8F%E5%BF%83%E6%8A%8A%E4%B8%80%E5%80%8B%E4%B8%8D%E7%9B%B8%E5%AE%B9%E7%9A%84%E6%94%B9%E7%89%88%E7%95%B6%E6%88%90%E4%BA%86%E6%AC%A1%E7%89%88%E8%99%9F%E7%99%BC%E8%A1%8C%E4%BA%86%E8%A9%B2%E6%80%8E%E9%BA%BC%E8%BE%A6)
版本格式：主版號.次版號.修訂號，版號遞增規則如下：
主版號：當你做了不相容的 API 修改，
次版號：當你做了向下相容的功能性新增，
修訂號：當你做了向下相容的問題修正。
先行版號及版本編譯資訊可以加到「主版號.次版號.修訂號」的後面，作為延伸。
如何[建立標籤](https://git-scm.com/book/zh-tw/v2/Git-%E5%9F%BA%E7%A4%8E-%E6%A8%99%E7%B1%A4)

## 參考資料
1. [30 天精通 Git 版本控管 (03)：建立儲存庫](https://ithelp.ithome.com.tw/articles/10132804)
2. [git 仓库迁移的两种方法](https://blog.csdn.net/hpu11/article/details/70597600)
3. [Git上的三種工作流程](https://medium.com/i-think-so-i-live/git%E4%B8%8A%E7%9A%84%E4%B8%89%E7%A8%AE%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B-10f4f915167e)
4. [git flow 實戰經驗談 part1 - 別再讓 gitflow 拖累團隊的開發速度](https://blog.hellojcc.tw/the-flaw-of-git-flow/)
5. [cherry](http://www.ruanyifeng.com/blog/2020/04/git-cherry-pick.html)