Git使用总结_第二节

Git远程仓库

Git是分布式版本控制系统，同一个Git仓库，可以分不到不同的机器上。每台机器都一个原始版本库，别的机器可以克隆这个原始版本库，而且每个版本库其实都是一样，没有主次之分。

实际情况往往是这样，找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。

Git分支管理

Git分支创建、切换速度很快，其它版本控制系统如SVN创建、切换较慢。

Git创建与合并分支

1. Git创建新的分支，如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向Dev上，就表示当前分支在dev上。
   
   所以，Git创建一个分支很快，因为除了增加一个dev指针，改HEAD的指向，工作区的文件都没有任何变化，所以很快。
2. Git新分支提交，创建完dev分支后，对工作区的修改和提交就针对dev分支了，新提交一次后，dev指针往前移动一步，而指向master的分支的master分支依然保持在原来的地方。
3. Git新分支合并至master分支，直接把master指向dev的当前提交，所以Git合并分支也很快，就只改指针，工作区内容不变。
   
4. Git删除分支，删除分支就是把dev指针给删掉，删掉后，就只剩下了一条master分支。
   
   总结

git 查看分支 git branch
git 创建分支 git branch <name>
git 切换分支 git checkout <name> 或者 git switch <name>
git 创建+切换分支 git checkout -b <name>或者 git switch -c <name>
git 合并某分支到当前分支：git merge <name>
git 删除分支：git branch -d <name>

Git解决冲突

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
用git log --graph命令可以看到分支合并图

Git分支管理策略

合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

1. Git合并分支，如果没有冲突，Git会使用 fast forward 模式，这种模式下，删除分支后，会丢掉分支信息。
2. 若需要强制禁用fast forward模式，Git就会再merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

git merge --no-ff -m "禁止使用fast forward快速合并"

1. 分支策略：
   团队合作分支如下图所示：
   
   master分支应十分稳定，仅用来发布新版本，平时不在上面干活。
   dev分支专门用来干活，不稳定，等版本发布的时候，再把dev分支合并到master上面，在master分支上发布稳定版本。

GitBug分支管理策略

1. 修复Bug时，若当前分支的工作正在开发，修复Bug会影响到当前分支的开发，此时需要创建新的Bug分支进行修复，然后合并，最后删除Bug分支。
2. 当手头工作没完成时，先把工作现场 git stash（暂存） 一下，然后去修复Bug，修复后，在git stash pop，回到工作现场。

 git stash 暂存工作区代码
     git stash list 查看所有的暂存工作区
     git stash apply 回复工作区代码，恢复后，stash内容并不删除
     git stash apply后，需要使用 git stash drop 来删除暂存
     git stash pop 恢复的同时把stash内容也删除了（推荐）

3. 在master分支上修改的Bug，想要合并到当前dev分支，可以**用git cherry-pick 命令，把Bug提交的修改"复制"到当前分支，**避免重复劳动。

git cherry-pick <commit> 把特定提交复制到当前分支

GitFeature分支管理策略

开发新feature时，最后新建一个分支，完成后，合并至Dev，最后删除该feature分支。

git branch -D <name> 丢弃一个没有合并过的分支，强行删除

Git多人协助分支管理策略

1. 多人协作，查看远程库的信息，使用git remote -v
2. 推送分支，git push origin master，推送其它分支，git push origin dev
   master、dev分支需要与远程同步，bug分支只用于在本地修改Bug，无需同步。
   feature分支是否推送到远程，取决于是否和同事合作开发。
3. 抓取分支，当从远程库clone时，默认情况下，只能看到本地的master分支 ，其它分支看不到，现在加入需要在dev分支上开发，就必须创建远程origin的dev分支到本地。

git checkout -b dev origin/dev创建远程origin的dev分支到本地，并建立与远程dev建立关联。

• 多人协作的工作模式
  1）用git push origin 推送自己的修改。
  2）若推送失败，则远程分支比本地分支更新，需要先用git pull试图合并。
  3）如果合并有冲突，则解决冲突，并在本地提交。
  4）没有冲突或冲突解决掉后，再用git push origin 推送就能成功。
  如果git pull 提示 no track information，则说明本地分支和远程分支的链接关系没有创建，用命令

git branch --set-upstream-to <branch-name> origin/<branch-name>

Git Rebase

rebase操作可以把本地未push的分叉提交历史整理成直线；
rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

git rebase

总结

小结：

• 查看远程库信息，使用git remote -v；
• 本地新建的分支如果不推送到远程，对其他人就是不可见的；
• 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
• 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
• 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
• 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

关于git clone只有master分支的问题

使用 git clone + 远程仓库地址将项目下载下来之后，倘若远程仓库有多个分支，我们会发现，使用git branch查看本地分支时，只有一个master分支
大多时候我们是需要在其他分支进行工作的，所以我们需要将远程的其他分支拉下来才可以，首先，先使用git branch -a查看远程分支,那些以rmotes开头且为红色的都是远程分支，或者理解为这些分支是隐藏的

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/develop
  remotes/origin/feature
  remotes/origin/feature-im
  remotes/origin/master
  remotes/origin/newbranch

若想要本地创建一个feature分支并和远程分支连接起来，需执行

git checkout -b feature origin/feature

或者使用-t参数，它默认会在本地建立一个和远程分支名字一样的分支

 git checkout -t origin/feature