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 之后，可以把删除掉的节点恢复。