git相关总结

1、git与svn区别

    集中式svn：自己电脑并没有版本库，每一次修改提交到中央服务器，假如没网络或者中央服务器挂了那就无法提交，也无法分支切换、管理

    分布式git：自己电脑本身有一套完整的版本库，各自开发提交到自己电脑的版本库，最终提交到中央服务器交换修改，假如没网或者中央服务器挂了，各自电脑上修改提交、分支管理，最终有网或者中央服务器正常的时候提交交换修改

2、分布式特点

所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道

Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的

3、提交操作命令

  git init： 初始化git

  git add <file>  ： git add . :文件修改添加到暂存区   

  git commit -m ‘提交备注’：暂存区的所有内容提交到当前分支。

4、版本回退

git log 或者   git log --pretty=oneline查看当前提交的日志信息

回退到指定版本：

git reset --hard HEAD^：HEAD当前版本； HEAD\^上一个版本 HEAD\^^ 上上一个版本 HEAD~3上3个版本  

git reset --hard 0e8704e 回到指定版本

回退后后悔，想要重新回到回退之前的版本：

git reflog 记录你的每一次命令操作，执行后，继续执行回到制定版本操作：git reset --hard 0e8704e

5:工作区与暂存区

git add命令实际上就是把要提交的所有修改从工作区放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

git diff HEAD -- 文件名 或者git diff HEAD可以查看工作区与暂存区的不同

6：撤销修改

（1）放弃工作区的修改

git  checkout -- 文件名。 或者git checkout .(放弃所有修改)

（2）暂存区恢复到add之前的状态（把暂存区的修改回退到工作区）

git reset HEAD 文件名 或者 git reset HEAD（）此次操作可以把暂存区的修改回退到工作区，接着用git checkout . 可以放弃工作区的修改，彻底放弃修改

（3）假如add了同时也commit了想要放弃，那就要执行上面的版本回退

版本回退和把暂存区的修改回退到工作区命令类似，中间多了--hard

7、远程仓库

关联：

git remote add origin git@github.com:michaelliao/learngit.git

推送

（由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令）

git push -u origin master

查看远程库文件的版本信息

git remote
git remote -v

解除绑定

git remote rm origin

克隆远程仓库

git clone git@github.com:michaelliao/gitskills.git

8：分支管理

git checkout -b dev 创建并切换到dev分支，等驾于下面语句
git checkout -b dev origin/dev 创建并从远程拉dev同步代码下来
git branch --set-upstream-to dev origin/dev//远程代码和本地分支同步代码

git branch dev  创建
git checkout dev  切换
git branch 查看当前分支（本地）
git branch -a（查看本地和远程）
git merge dev 把dev上的代码合并到当前分支

实际上最新版本的Git提供了新的git switch命令来切换分支

git switch -c dev 创建并切换到新的dev分支

git switch master 直接切换到已有的master分支

分支合并解说，

$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

上面的Fast-forward，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，后面再讨论其他的合并模式，

禁用fast-forward模式，

git merge --no-ff -m "merge with no-ff" dev

合并完成后可以删除dev分支

git branch -d dev //删除本地分支
git branch -D dev //强行删除（有时分支改了没合并执行-d会报错，用-D）
git push origin :dev //删除远程分支

通过带参数的git log 可以实现查看合并情况

其中--graph图表展示合并路线 --pretty=oneline一条线美观 --abbrev- commit简写commit id 

git log --graph --pretty=oneline --abbrev-commit

9：分支策略

master：分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；因此要时刻与远程同步

dev：每个人都有自己的分支，时不时地往dev分支上合并就可以了。分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

 bug分支：(改完删除)

场景：线上版本是master，目前正在dev分支做开发，突然线上环境出了bug需要紧急修复，但不提交dev，因为工作没做完，如何切换到master？

git stash 把工作现场藏起来，操作之后git status查看，工作区是干净的，然后切换master ，新建bug分支，修改，合并上线

git stash

如何恢复藏起来的工作区？

git stash list
查看藏起来的工作区

git stash apply//恢复，（不删除）
git stash drop //删除
git stash pop //删除并恢复
git stash list//查看
git stash apply stash@{0}//恢复指定的收藏

修改的bug怎么同步到dev上？

首先不是merge master上的提交过来，而是通过cherry-pick命令，把master上的某一次提交 cherry-pick过来

git cherry-pick 4c805e2

Git自动给dev分支做了一次新的提交

feature分支：

一般新的功能新迁一个feature分支出来，改完合并到dev，删除

10：rebase操作

当在feature分支上执行git rebase master时，git会从master和featuer的共同祖先B开始提取feature分支上的修改，也就是C和D两个提交，先提取到。然后将feature分支指向master分支的最新提交上，也就是M。最后把提取的C和D接到M后面，注意这里的接法，官方没说清楚，实际是会依次拿M和C、D内容分别比较，处理冲突后生成新的C’和D’。一定注意，这里新C’、D’和之前的C、D已经不一样了，是我们处理冲突后的新内容，feature指针自然最后也是指向D’，原文链接：https://blog.csdn.net/weixin_42310154/article/details/119004977