Open wtysos11 opened 3 years ago
git尽管是很简单的工具,但是一些操作还是比较复杂的。通过熟练掌握git能极大提高编程时的幸福指数。
其他文档:
同步远端分支变化
git fetch origin master
git fetch
git fetch -p
都是先git fetch,然后再执行合并操作。其中git pull执行的是git merge,而git pull -r执行的是git rebase
git pull
git merge
git pull -r
git rebase
git pull origin master
git pull -r origin master
向远端更新分支
git push origin master
git push origin :branch
git push origin -d branch
回滚代码和切换分支
git checkout -- files
git checkout branch
git checkout -b branch
git merge master与git rebase master
git merge master
git rebase master
git rebase的原理:
在不断rebase master的时候,commitID会发生大量的变化。因此,不要在公共的分支上使用rebase。
这个是目前用的比较多,也感到比较困惑的命令。一般的使用场景是在开发feature分支的时候将指定的几个修复bug的commit同步到master上,并进行对应的测试来完成跨分支fix bug的操作。但是如果出现了冲突,或者说我只想要cherry-pick提交记录中的某一个文件的修改应该怎么办?
记录了所有的git命令操作,特别是每一个commitID
基本操作的补充
冲突文件阅读
冲突操作处理
Conventional commits,angular提交准则
Git仓库包含三部分:本地代码、缓存区、提交历史
四个场景:工作区workspace、修改后提交的缓存staging,本地仓库local repository和远程仓库remote repository
每个commit都是一个完整的代码状态,使用一个commit ID来进行唯一标志
从某种程度上说,Git所维护的就是一个commit的树
分支可以看做是一个平行宇宙,本质是修改了头指针。
之前写的一篇:git分支开发模式学习,如何利用好分支在git上开发
需要回溯某个指定文件到某个指定版本,或者回溯某一群文件到指定版本。更高级的需求是回溯的同时保留某几次的修改。
场景:经常会有这种情况,对于一个文件中的某个操作被证明是有问题的。比如对于文件A修改了段落A、段落B、段落C,提交的commit分别是提交a、提交b和提交c。最后发现提交a是有问题的,但是如果直接回溯的话会将提交b和提交c也回溯掉。现在采用的方法是直接手动切换到提交a,运用diff查看到底改了什么,再切回提交c进行对应的修改。
在开发过程中经常会有很多分支,有时候需要将某个分支中的某个文件更新到当前分支中。
之前所使用的方式是手动切入到该分支,复制出文件内容,再切回当前分支,提交对应的修改。
正确的方式:
这个也是经常出现,比如在提交的时候不小心将某个超大文件(5GB)给塞进了commit中,如果要推到远端的话下载的人估计心态能直接炸掉。
如果距离比较接近还可以直接revert掉重新提交,代价是所有的commit记录全部丢失。但是如果距离比较远的话应该如何处理?怎么样在保留提交记录的同时删除掉这个大文件
合并分支的过程中需要解决冲突,ours 和 theirs,以及merge 和 rebase,对象为整个分支、目录或者文件
git尽管是很简单的工具,但是一些操作还是比较复杂的。通过熟练掌握git能极大提高编程时的幸福指数。
其他文档:
基本操作
git fetch
同步远端分支变化
git fetch origin master
,拉取指定分支的变化git fetch
,拉取所有分支git fetch -p
,拉取所有分支的变化,同时将远端不存在的分支同步移除git pull
都是先
git fetch
,然后再执行合并操作。其中git pull
执行的是git merge
,而git pull -r
执行的是git rebase
git pull origin master
,git pull -r origin master
git push
向远端更新分支
git push origin master
git push origin :branch
或者git push origin -d branch
,删除远端分支git checkout
回滚代码和切换分支
git checkout -- files
回滚指定代码文件git checkout branch
切换分支git checkout -b branch
新建分支git merge
与git rebase
git merge master
与git rebase master
git rebase的原理:
在不断rebase master的时候,commitID会发生大量的变化。因此,不要在公共的分支上使用rebase。
git branch
进阶操作
git rebase
cherry-pick
这个是目前用的比较多,也感到比较困惑的命令。一般的使用场景是在开发feature分支的时候将指定的几个修复bug的commit同步到master上,并进行对应的测试来完成跨分支fix bug的操作。但是如果出现了冲突,或者说我只想要cherry-pick提交记录中的某一个文件的修改应该怎么办?
git reflog
记录了所有的git命令操作,特别是每一个commitID
git alias
细节操作
基本操作的补充
处理冲突
冲突文件阅读
冲突操作处理
diff结果阅读
git commit 提交规范
Conventional commits,angular提交准则
原理
git核心
Git仓库包含三部分:本地代码、缓存区、提交历史
四个场景:工作区workspace、修改后提交的缓存staging,本地仓库local repository和远程仓库remote repository
提交
每个commit都是一个完整的代码状态,使用一个commit ID来进行唯一标志
从某种程度上说,Git所维护的就是一个commit的树
分支
分支可以看做是一个平行宇宙,本质是修改了头指针。
开发模式
之前写的一篇:git分支开发模式学习,如何利用好分支在git上开发
操作Q&A
文件回溯
需要回溯某个指定文件到某个指定版本,或者回溯某一群文件到指定版本。更高级的需求是回溯的同时保留某几次的修改。
场景:经常会有这种情况,对于一个文件中的某个操作被证明是有问题的。比如对于文件A修改了段落A、段落B、段落C,提交的commit分别是提交a、提交b和提交c。最后发现提交a是有问题的,但是如果直接回溯的话会将提交b和提交c也回溯掉。现在采用的方法是直接手动切换到提交a,运用diff查看到底改了什么,再切回提交c进行对应的修改。
分支迁移
在开发过程中经常会有很多分支,有时候需要将某个分支中的某个文件更新到当前分支中。
之前所使用的方式是手动切入到该分支,复制出文件内容,再切回当前分支,提交对应的修改。
正确的方式:
大文件删除
这个也是经常出现,比如在提交的时候不小心将某个超大文件(5GB)给塞进了commit中,如果要推到远端的话下载的人估计心态能直接炸掉。
如果距离比较接近还可以直接revert掉重新提交,代价是所有的commit记录全部丢失。但是如果距离比较远的话应该如何处理?怎么样在保留提交记录的同时删除掉这个大文件
合并分支的倾向性
合并分支的过程中需要解决冲突,ours 和 theirs,以及merge 和 rebase,对象为整个分支、目录或者文件