公司中常用的一些git命令和常见情况

一：常见的git指令

• 查看分支 git branch -a
• 创建分支 git branch name
• 切换分支 git checkout name
• 创建并切换 git checkout -b name
• 合并某分支到当前分支 git merge name
• 删除分支 git branch -d name

二：分支管理策略

• 主分支 master
  代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。 Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

• 开发分支 develop
  主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。这个分支可以用来生成代码的最新代码版本。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）

• 功能分支 feature
  功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。 功能分支的名字，可以采用feature-*的形式命名。

• 预发布分支 release
  预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面 分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。

• bug 分支 fixbug
  bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。

• 其它分支 other
  还有就是其它分支了，大家可以根据需要创建即可……

三：场景：你是第—天来公司上班的，项目代码托管在GitLab，目地址：git@lab.com:org/project.git，现在有—处代码需要你修改。请完成此项任务中，与 git/gitlab相关的操作步骤。

四：如果线上出现bug，git怎么操作？

方法1在当前主分支修改bug，暂存当前的改动的代码，目的是让工作空间和远程代码—致：

Git stash

修改完bug后提交修改：

git add .

git commit —m “fix bug 1”

git push

从暂存区把之前的修改恢复，这样就和之前改动—样了

git stash pop

这时可能会出现冲突，因为你之前修改的文件，可能和bug是同—个文件，如果有冲突会提示：

Auto—merging xxx.Java

CONFLICT (content): Merge conflict in xxx.java

前往xxx.java解决冲突

注意stash pop意思是从暂存区恢复到工作空间，同时删除此条暂存记录

方式2：拉—个新分支，老司机都推荐这样做，充分利用了git特性，先暂存—下工作空间改动：

git stash

新建—个分支，并且换到这个新分支

git branch fix_bug //新建分支

git checkout fix_bug //切换分支

这时候就可以安心的在这个fix_bug分支改bug了，改完之后：

git add .

git commit —m “fix a bug”

切换到master主分支

git checkout master

从fix_bug合并到master分支

git merge fix_bug

提交代码

git push

然后从暂存区恢复代码

git stash pop

此时如有冲突，需要解决冲突

五：git与svn的区别

git是分布式的，svn不是。

git跟svn—样有自己的集中式版本库或服务器。但git更倾向于被使用于分布式模式，克隆版本库后即使没有网络也能够commit文件，查看历史版本记录，创建项目分支等，等网络再次连接上Push到服务器端。

git把内容按元数据方式存储，而svn是按文件。

所有的资源控制系统都是把文件的元信息隐藏在—个类似.svn,.cvs等的文件夹里。

git目录是处于你的机器上的—个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分支，版本记录等。

git没有—个全局的版本号，svn有。

git的内容完整性优于svn。因为git的内容存储使用的是SHA-1哈希算法。

git可以有无限个版本库，svn只能有—个指定中央版本库。

当svn中央版本库有问题时，所有工作成员都—起瘫痪直到版本库维修完毕或者新的版本库设立完成。

每—个git都是—个版本库，区别是它们是否拥有活跃目录（Git Working Tree）。如果主要版本库（例如：置於GitHub的版本库）有问题，工作成员仍然可以在自己的本地版本库（local repository）提交，等待主要版本库恢复即可。工作成员也可以提交到其他的版本库！

六：git分支git pull --rebase 跟git pull 什么区别

git pull分别做了两个操作分别是获取和合并。添加了rebase就是以rebase的方式进行合并分支，默认使用merge方法。

在情景中看看merge和rebase的具体区别：

情景：当在feature分支进行开发，master分支也有新的提交

merge

指令：

git checkout feature  //切换到feature分支
git merge master  //将master合并到当前分支

原理：git会自动根据两个分支的共同祖先即2这个commit和俩个分支的最新提交即4和7进行一个三方合并，并将合并中修改的内容生成一个新的commit，即8。简单来说就是合并两个分支并生成一个新的提交。

如果合并的时候遇到冲突，仅需要修改后重新commit

优点：记录了真实的commit情况，包括每个分支的详情

缺点：当commit比较频繁时，分支会很杂乱

rebase

指令：

git checkout feature  //将分支切换到feature
git rebase master  //将开发中的master分支合并到当前稳定feature分支

原理：这些命令会把你的feature分支里的每个提交（commit）5、6、7取消掉，并且把它们临时作为补丁保存到".git/rebase"目录中,然后把"feature"分支更新 为最新的"master"分支，最后把保存的这些补丁应用到"feature"分支上。feature分支更新之后，它会指向这些新创建的提交（commit），之前的commit会被删除，运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除.

优点：这样的好处是干净，分支上上不会有无意义的解决分支的commit；

缺点：如果合并的分支中存在多个commit，需要重复处理多次冲突。

七：一个分支节点，你和你同事一起开发，你同事已经提交了，你要提交怎么做

1. 首先保存本地修改git commit //将暂存区里的改动给提交到本地的版本库或者直接push到git/gerrit（只是上传，不合并分支）
2. git pull --rebase更新远程代码到本地
3. 此时可能产生冲突，需要手动修改代码解决冲突（此时是在某个解决冲突的节点上，并不是在分支上）
4. 解决完冲突后，get rebase --continue从解决冲突的节点回到分支，此时解决冲突的那些修改已经保存到分支的git记录中
5. git add添加新的修改到暂存区
6. git commit --amend追加提交到刚刚一开始没有合并的提交中
7. git push origin ......//将当前分支推送到origin主机的对应分支
8. git merge

补充问题：为什么要先commit，然后pull，然后再push

这个先 commit 再 pull 再 push 的情况就是为了应对多人合并开发的情况：
1、commit 是为了告诉 git 我这次提交改了哪些东西,不然你只是改了但是 git 不知道你改了,也就无从判断比较;
2、pull是为了本地 commit 和远程commit 的对比记录,git 是按照文件的行数操作进行对比的,如果同时操作了某文件的同一行那么就会产生冲突,git 也会把这个冲突给标记出来,这个时候就需要先把和你冲突的那个人拉过来问问保留谁的代码,然后在 git add && git commit && git pull 这三连,再次 pull 一次是为了防止再你们协商的时候另一个人给又提交了一版东西,如果真发生了那流程重复一遍,通常没有冲突的时候就直接给你合并了,不会把你的代码给覆盖掉
3、出现代码覆盖或者丢失的情况:比如A B两人的代码pull 时候的版本都是1,A在本地提交了2,3并且推送到远程了,B 进行修改的时候没有commit 操作,他先自己写了东西,然后 git pull 这个时候 B 本地版本已经到3了,B 在本地版本3的时候改了 A 写过的代码,再进行了git commit && git push 那么在远程版本中就是4,而且 A 的代码被覆盖了,所以说所有人都要先 commit 再 pull,不然真的会覆盖代码的