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 rebasegit pull origin master，git pull -r origin mastergit push
向远端更新分支
git push origin mastergit push origin :branch或者git push origin -d branch，删除远端分支git checkout
回滚代码和切换分支
git checkout -- files回滚指定代码文件git checkout branch切换分支git checkout -b branch新建分支git merge与git rebasegit merge master与git rebase mastergit 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，对象为整个分支、目录或者文件