我在团队的技术分享-Git日常操作我在团队的技术分享-Git日常操作
我在团队的技术分享-Git日常操作我在团队的技术分享-Git日常操作
今天在公司内做了一次关于Git操作的分享，总结准备了几天，写了二十多页的ppt，在紧张结巴中大约讲了三四十分钟，带大家一起回顾了Git日常操作。
简介
Git的诞生、背景故事、balabalabala纯碎凑时间。。。
分布式和集中式的各自特点，其实也就比较下Git和SVN。
- workspace: 工作区
- index/Stage: 暂存区
- Repository: 本地仓库
- Remote: 远程仓库
工作流程如下： 1、从远程仓库克隆代码到本地仓库 2、在本地仓库中checkout代码然后进行代码修改 3、在提交代码前先将代码提交到暂存区 4、提交到本地仓库。本地仓库中保存修改的各个历史版本 5、修改完成后，需要和团队共享代码时，将代码push到远程仓库
安装与配置
客服端、服务端等balabalabalabalabala。。。
常用命令
git branch //查看本地分支
git branch -l//本地分支
git branch -r //远程分支
git branch -a //全部分支
git branch dev //创建分支Dev
git checkout dev//切换到Dev
git checkout -b dev //创建分支并切换过去
git branch -d dev //删除分支
git branch -D dev //删除分支-强制删除
git branch –m 当前分支名 新的分支名
git branch -v 可以查看包括分支指向的ID及提交信息
git add .
git commit -m'注释信息'
git clone
git fetch
git pull
git push
git push origin :test(远程的分支) //刚提交到远程的test将被删除，但是本地还会保存的
git push origin dev:dev //创建新的远程分支- 关于分支删除: 删除分支前需要先切换到其他分支才能进行删除操作。如果要强制删除分支的话可以使用指令： git branch -D <分支名> 不管该分支有没有合并到当前分支的提交记录都进行删除。
- 恢复分支 对于已经有提交记录的分支删除后，实际上只是删除指针其commit记录还被保留，恢复之前我们可以通过指令： git reflog查找该分支最后一次提交时的ID（最前面的hash值）， 我们可以根据ID创建新的分支来恢复之前的分支数据。 恢复指令为：git branch <分支名> <hash值> ，当然你也可以从远程仓库重新clone一份。
标签相关
git tag //查看标签
git tag -a 标签名 -m "注释" //创建tag
git push origin —tags //提交标签到远程仓库，把本地的打的标签全部提交到远程仓库。
git tag -d v1.01//删除标签
git push origin :refs/tags/v1.01 //删除远程标签， 冒号前为空表示删除远程仓库的tag。
git push origin --delete tag 0.0.1分支合并
关于分支合并有三种操作形式：
- git merge
- git rebase
- git cherry-pick
最简单的、最快的合并场景，快速合并
合并目标分支,按照commit提交时间合并；
有交叉节点的分支合并
H-I-J topic
/ \
A-B-C-D-E-F - k master合并后沿着master分支和topic分支创建一个记录合并结果的新节点，该节点带有用户描述合并变化的信息。
git merge --abort //合并后导致冲突时才使用,撤销合并过程中的操作回到初始状态；
一个分支的个别提交合并到另一个分支
应用场景：在一个分支上做了修改commit , 结果发现本次修改也适用于其他分支、或者bug修复；此时可以把本次提交单独合并到目标分支去，而不是执行git merge 合并；
也可以一次合并多个提交
git cherry-pick id1 id2
遇到冲突后，解决git add .
使用下面的命令，让 Cherry pick 过程继续执行。
git cherry-pick --continue
git cherry-pick --abort//发生代码冲突后，放弃合并，回到操作前的样子;变基 rebase
如下场景
分支1 、分支2都是独立的需求模块，已各自开发完毕；
stable分支就是我们的本地主分支和生产保持同步(其实它比远程分支快几个版本)；
期望合并后如下：
此时唯有变基才能实现，保持各个需求commit在一起，看起来很好看；
> git checkout branch1
> git rebase stable //合并branch1到stable分支，会改变作业分支的基线俗称变基。
从两分支共同节点开支，全部取消作业分支branch1的commit打包成补丁，然后把分支1之后所有的提交合并过来，
作业分支的补丁放到后面，也就是作业分支基线变了，变到了分支1后面。
最后合并的结果，不在是时间顺序排。
此过程可能会出现冲突，解决相应的冲突，执行git add . ，此时不需要commit。然后继续
> git add . //把有冲突的修改添加到暂存区，不用commit;
> git rebase --continue 继续执行后续操作。
git rebase --abort 撤销操作回到初始状态此时branch1 合并完成:[master -> C31-> C32-> C33-> C11-> C12-> C13]
然后合并branch2
> git checkout branch2
> git rebase branch1 //其他操作同上步骤，如有冲突继续解决；此时branch2 合并完成:[master -> C31-> C32-> C33-> C11-> C12-> C13-> C21-> C22-> C23]
至此合并完成，分支变基成功，达到了想要的结果；
暂存
应用场景:正在作业分支，突然要去其他分支修改点东西，暂存当前作业，使其恢复到初始状态。然后去目标分支愉快的工作，后来后再恢复原来的暂存，回到曾经的模样，继续工作。
git stash save 备注信息 //暂存当前作业分支的修改；
git stash list //查看本地所有暂存信息
git stash pop //暂存恢复
git stash pop {i} //恢复指定索引的暂存,恢复后删除原来暂存信息
git stash apply {i} //恢复指定索引的暂存,恢复后不会删除原来暂存信息
git stash drop {i}//删除指定索引的暂存
我的本地暂存示例
撤销回滚
首先明确一点，根据工作区所处的不同状态，撤销的方式不同；
git撤销操作主要有三种方式：
-
git reset--soft 不删除工作空间的改动代码 ，撤销commit，不撤销git add file --hard 删除工作空间的改动代码，撤销commit且撤销add
会改变分支的状态，删除commit节点；
git restore是关于从索引或另一个提交还原工作树中的文件。 此命令不会更新您的分支。该命令还可用于从另一个提交还原索引中的文件。git-revert生成新的commit对象,覆盖原有的提交，会改变分支的状态，增加commit；
所以可以看出git reset是删除commit对象，如果为了保留每次变更记录，使用git revert命令。
git-revert 根据操作的目标commit来源不同，操作方式也不同。
对于 merge类型的commit对象，还需要“-m”参数
git revert -m 1 commit-id
对于普通的commtit对象
git revert commit-id
理解了三种撤销方式，知道了自己当前工作状态，就可以选择不同的方式随意操作了；
日志相关
其中git reflog记录了我们Git本地所有操作活动，任何撤销、删除、提交的节点都这这里；
Git、SVN比较
都是其他地方贴过来的，随便吹水的，，，，
（1）基本操作大致相同；
（2）SVN没有本地库，GIT有本地库；
（3）SVN提交代码时只需一次提交（远程库），GitHub需要两次提交（本地库一次，远程库一次）；
（4）GitHub适用于分布式开发，SVN使用于集中式开发；
（5）就操作难易程度而言，SVN要比GitHub方便得多；就代码管理而言，GitHub更优。
SVN的缺点：
当无法连接到中央版本库的环境下，就无法提交代码，将代码加入到版本控制，也就说明基本上无法工作
由于每一次提交都保留一个原始副本，因此SVN数据库容量可能会暴增。
由于代码集中管理，存在单点故障，所以需要对svn中央版本库的存储进行备份，而且同时还要备份所有更改的版本记录