GIT干货分享

GIT干货分享

*宁静致远,天道酬勤

git配置

git config --global user.name ‘xxx’
git config --global user.email ‘xxx’

  • config的三个作用域
  1. git config --local 只对某个仓库有效
  2. git config --global 对当前用户所有仓库有效
  3. git config --system 对系统所有登录的用户有效
    缺省等同于local
    查看当前配置 git config --list [–global]

工作区,暂存区,版本库

工作区:
本地进行修改后,git add 之前,内容都在工作区中
暂存区:
本地修改后,git add 之后,内容都在暂存区中
版本库:
git commit 之后,内容就到了版本库中
GIT干货分享_第1张图片

分离头指针(detached HEAD)

[外链图片转存失败(img-YkTSVEQZ-1563894064658)(./图片/detached_head.jpg)]
通常,我们工作在某一个分支上,比如 master 分支。这个时候 master 指针和 HEAD 指针是一起前进的,每做一次提交,这两个指针就会一起向前挪一步。但是在某种情况下(例如 checkout 了某个具体的 commit),master 指针 和 HEAD 指针这种「绑定」的状态就被打破了,变成了分离头指针状态。如果此时又做了一次新的提交时,HEAD 指针跑到 master 指针前面去了。如果我直接检出 master 分支,HEAD 指针就会回退一格到 master 指针的位置,而最新的那次提交就变成了孤立的提交,没有任何分支能追踪到它,那么这个提交就废掉了,所以这个时候需要新建一个分支与其关联
GIT干货分享_第2张图片

解决办法:
git branch -f master HEAD 强制将 master 分支指向当前头指针的位置
git checkout master 检出 master 分支
或者
git branch [branch_name] xxx,新建一个分支,并且和xxx分支绑定

GIT常用命令

  • 初始化仓库

git init

  • 查看版本历史

注意,历史分为提交历史和命令历史
git log 查看当前分支所有提交历史
git log --oneline 查看简易历史
git log -n2 查看最近的2次历史
git log --graph 带有演进图的历史
git log --all 查看所有分支所有历史
git reflog 查看命令历史

  • 查看本地有多少分支

git branch -v

  • 查看远程有多少分支

git branch -a

  • 删除分支

git branch -d xxx 或者 git branch -D xxx

  • 修改最新commit的message

git commit --amend 直接修改保存即可

  • 修改老旧commit的message

git rebase -i xxxxx(要变更的commit的上一个commit) ,想修改的改为reword,保存,在新界面中修改commit信息,保存退出

  • 把多个commit合并为一个commit

git rebase -i xxxx,在想合并的commit中,pick一个,然后squash其他的,在新界面中写为什么合并commit,保存退出

  • 把间隔的commit合并为一个commit

git rebase -i xxxx, 将想合并的commit复制到一起,然后仿照上面的步骤即可

  • 比较暂存区和HEAD差异

git diff --cached

  • 比较工作区和暂存区差异

git diff --文件名 ,如果不加文件名,显示所有文件diff

  • 恢复暂存区到HEAD

git stash,保存工作区内容,git reset HEAD – 文件名,如果不见文件名,恢复所有文件

  • 恢复工作区到暂存区

git checkout --文件名
所以,如果想变更暂存区内容,用reset,如果想变更工作区内容,用checkout

  • 恢复到历史的某次提交中

git reset --hard xxxx

  • 查看不同提交的指定文件差异

git diff xxx xxx --文件名,如果不加文件名,显示所有差异,同时如果想查看不同分支的差异,也是这个命令,xxx改为分支名

  • 删除文件,重命名文件(不常用)

git rm 文件名,git mv 文件名 (不常用,一般都是直接删除,然后add,commit)

  • 暂存、恢复工作区内容

git stash 保存
git stash pop(pop后,stash列表中的内容消失),或者 git stash apply(stash列表中的内容仍然存在,可反复使用)
git stash list 查看stash 列表中的所有备份
git stash clear 删除所有备份

  • gitignore 文件

gitignore中的文件,git不会再管理

  • 保存工作区到暂存区

git add .

  • 保存暂存区到HEAD

git commit -m “xxxx”, xxx为提交的内容

  • 克隆远程仓库到本地

git clone xxx

  • 查看远程仓库

git remote 列出已经存在的远程分支

  • 添加远程仓库

git remote add [name] [url]

  • 抓取远程仓库分支

git fetch xxx

  • 提交

git push origin ,将当前分支推送到origin对应的分支
而在gerrit上面,由于需要code review,所以提交时需要:git push HEAD:refs/for/[branch_name]

  • 打标签

可以为某次提交打标签
查看标签: git tag
为历史某个commit新建标签: git tag -a 标签名字 xxxx,xxx为某次提交的commit_id
为当前commit新建标签(含附注的):git tag -a 标签名字 -m’标签信息’
为当前commit新建标签(不含附注的): git tag 标签名字
所有的标签操作都是打在本地的,需要手动提交,才可以在远程仓库生效: git push origin 标签名字
如果想一次推送所有的本地新增标签到远程:git push origin --tags

git配置公私钥

cd ~/.ssh
ssh -keygen -t ras -C ‘电子邮件地址’

多人协作

  • 克隆远程分支到本地

git checkout -b 本地分支名字 origin/远程分支名字

  • 拉取远程分支最新修改

git pull 或者 git pull --rebase

  • git pull :
    git pull ,实际执行的是两个步骤:git fetch 和 git merge
  • git pull --rebase:
    git pull --rebase,实际执行的是两个步骤:git fetch 和 git rebase

git merge 会新建一个提交,将本地修改与远程分支合并后,添加到远程分支上,在多人merge时,就会有多条历史提交线,如下图:
GIT干货分享_第3张图片
git rebase 会将本地的提交检出,与远程分支合并后,只保留一个提交线,如下图:
GIT干货分享_第4张图片

  • 拉取远程更新,出现冲突时:

出现冲突原因:两个人对一个文件同一个区域做了修改
问题:如果两个人对一个文件的不同区域做修改,那么这个文件会显示冲突吗? 答:不会
解决冲突的方法:

  1. 对于冲突的文件,解决冲突
    GIT干货分享_第5张图片
  2. HEAD表示本地修改,xxx表示当前远端修改,选择想保留的
    GIT干货分享_第6张图片
  3. 解完所有冲突后:
  • 如果用的是 git pull
    git add . 然后 git commit -m “”
  • 如果用的是 git pull --rebase
    git add . 然后 git rebase --continue
  1. git push
  2. 如果解决冲突的过程中,想恢复pull之前的状态
  • 如果用的是 git pull
    git merge --abort
  • 如果用的是 git pull --rebase
    git rebase --abort
  • 同时修改了文件名和文件内容怎么办?

答:凉拌
->如果变更了文件名的同学先提交,则变更了文件内容的同学,是不会提交成功的,此时需要git pull 拉取最新的修改,而这个时候,git是可以自动完成修改的

  • 所以,正确的操作习惯很重要!

  • 同时修改了同一个文件的文件名怎么办?

答:还是凉拌
这个时候,还是提示冲突,此时会有两个文件,选择希望保留的文件即可(注意丢弃的那个文件是否有修改需要保存)

git 的fast forward 和 no fast forward

  • fast-forward的话则是直接合并,看不出之前Branch的任何记录

  • –no-ff 指的是强行关闭fast-forward方式。–no-ff (no fast foward),使得每一次的合并都创建一个新的commit记录,即要求git merge即使在fast forward条件下也要产生一个新的merge commit,用来避免丢失信息。但是这个实际用起来很麻烦。
    GIT干货分享_第7张图片

多人协作时的一些禁忌

  • git push -f

强制提交,无异于删库跑路

  • 不要改变历史commit的内容

认为历史commit太多太乱,所以整理了一下,将历史某几个commit合并为一个commit

执行了上面这个操作后,就导致该分支上面的commit信息变更,而其他人的本地commit信息仍然是旧的commit信息,此时是不能执行fast_forward操作的,那么这个时候,如果你有多次提交,别人就需要每个提交一个一个的去pull,然后解冲突,,,想想针对同一个文件别人解n次冲突,会不会被打-.-
注意这里的改变历史,不包括修改历史commit的message

工作时正确的操作习惯

  1. 每天到了公司,首先 git pull --rebase ,拉取最新的修改,再做开发任务
  2. 开发过程中,如果一个修改需要耗时几天,或者修改变动特别大,将修改分解为几步,当每一步完成并且验证ok后,及时提交到远程

这个的目的是: 避免改动过大,而其他同学在这个文件也做了修改,导致pull的时候冲突太多

  1. 开发完成后,正确的提交流程为:
  1. git pull --rebase 拉取最新修改
  2. 如果有冲突,解决冲突
  3. 解决完成后,git push
  1. merge时的操作
  1. 假如现在有A分支和B分支,希望把A分支merge到B分支上
  2. 首先,将A,B两个分支都pull到最新状态
  3. 在B分支上执行 git merge A
  4. 如果没有冲突,万事大吉,如果有冲突,解决冲突,然后 git add . 然后 git commit -m""
  5. git push
  1. 上线后,需要在上线的分支的commit上打上标签,标签名字为上线的版本信息,方便线上有问题可以回滚
  2. 一个比较好的实践是:

远程master分支为线上分支,永远保证正确,可以随时上线。
远程基于master分支拉出的dev分支,作为公共开发分支,具备所有的新功能,可以随时发布测试版本。
个人在本地基于dev分支拉出feature分支,开发自己的任务,当自己的任务完成,并且本地验证ok后,再推送到dev分支。

其他

  • 使用github创建自己的博客

开源项目:jekyll-now ,只需要3步,按照步骤操作即可
GIT干货分享_第8张图片

你可能感兴趣的:(git)