git submodule臨時分支；以及git reset使用

submodule

已經創建好了一個gitlab submodule形式的repo：

在repo A下面有一個submodule B， A --> B。

clone -b branch [repoA]
cd A
git submodule update --init

以後，在B的文件夾下運行

git branch

會發現當前分支處於一個臨時分支上：

 (HEAD detached at 3bf1f88)

可是在提交repoA的時候，更新的是B中的production分支：

git submodule foreach git co -b production
git submodule foreach git pull origin production

而pull下來以後倒是在臨時分支上。

搜索一陣以後，結論是：

1. repoA中只會保存repoB的某一個commit，而不知道（或者無論）這個commit是哪一個分支的。update以後submodule都會在一個臨時分支上。

2. 在更新repoA中的submodule時，須要到每個submodule中進行操做，若是全部submodule分支名都相同，那麼可使用git submodule foreach命令。

3. 若是想要repoA和repoB的分支名相同，好比repoA的production分支指向submodules的production分支，須要保證在更新時讓repoA指向repoB的production分支的最新的commit，而不是在clone和pull代碼時讓repoB改成production分支。

4. 使用repoA時，能夠不用管repoB正處在臨時分支上，由於提交repoA代碼的時候保證了repoB的commit是目標分支上的，此時repoB的代碼就是想要的版本。

新建一個submodule repo過程參考https://blog.csdn.net/czhpxl007/article/details/50555853

 

reset

正好碰到了一個需求：在一個本地分支上提交了幾個commit以後，如今想回到以前一個一個節點上，可是修改的內容也要保存下來。

之前一直使用 git reset --hard commitID，可是--hard參數不會保存修改的內容，會把全部的變化所有刪除。

研究一番以後，發現 --soft 和 --mixed參數均可以解決這個問題。

先轉載一段介紹https://www.cnblogs.com/kidsitcn/p/4513297.html

Index
index也被稱爲staging area，是指一整套即將被下一個提交的文件集合。他也是將成爲HEAD的父親的那個commit

Working Copy
working copy表明你正在工做的那個文件集

Flow
當你第一次checkout一個分支，HEAD就指向當前分支的最近一個commit。在HEAD中的文件集（實際上他們從技術上不是文件，他們是blobs（一團），可是爲了討論的方便咱們就簡化認爲他們就是一些文件）和在index中的文件集是相同的，在working copy的文件集和HEAD,INDEX中的文件集是徹底相同的。全部三者(HEAD,INDEX(STAGING),WORKING COPY)都是相同的狀態，GIT很happy。

當你對一個文件執行一次修改，Git感知到了這個修改，而且說：「嘿，文件已經變動了！你的working copy再也不和index,head相同！」，隨後GIT標記這個文件是修改過的。

而後，當你執行一個git add,它就stages the file in the index，而且GIT說：「嘿，OK，如今你的working copy和index區是相同的，可是他們和HEAD區是不一樣的！」

當你執行一個git commit,GIT就建立一個新的commit，隨後HEAD就指向這個新的commit，而index,working copy的狀態和HEAD就又徹底匹配相同了，GIT又一次HAPPY了。

其實也就是經過git add和git commit進行狀態變動。

--soft參數：

soft參數會恢復到git add以後git commit以前，也就是把變動記錄到了index區。此時HEAD指針指向了恢復到的commitID

--mixed參數:

mixed參數會直接恢復到git add以前，即全部更改都還在工做區，沒有任何提交動做，HEAD指針同soft參數同樣。mixed參數也是git reset的默認參數

因此爲了知足需求，使用git reset --soft commitID就行。

PS. 使用--hard以後，雖然全部更改都刪除了，可是commitID仍然還在，再使用git reset --hard latestCommitID 以後，能夠把刪除掉的節點恢復。