（三）分支管理
其他VCS如SVN等都有分支管理，但其创建和切换分支很慢，远不如Git。
git中HEAD严格说不是指向提交，而是指向master，master才是指向提交的，所以HEAD指向的就是当前分支。
例如：创建新的分支时git新建了一个指针，假设为dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上。
若在dev上的工作完成了，便可把dev合并到master上。最简单的合并方法就是直接把master指向dev 的当前提交。合并后，若dev分支没用了便可删除了。
1. 创建与合并分支
git checkout -b dev 创建并切换到dev分支
或先创建git branch dev，再切换git checkout dev
git branch 查看当前分支（当前分支前标有一个*号）
git merge name 合并指定分支(名为name)到当前分支
合并时出现的“Fast-forward”是指此次合并是“快进模式”，即直接把所在分支指向指定分支的当前提交，所以合并速度很快。但并非每次都能Fast-forward，还有其他方式的合并。
git branch -d name 删除名为name的分支
关于switch：
切换到名为name的分支：
git checkout name 或 git switch name
git switch -c name 创建并切换到新的name分支
Git 切换分支时会把未add或未提交的内容带过去。因为未add或未提交的内容不属于任何一个分支，即对于所有分支而言，工作区和暂存区是公共的。
可用git stash暂存现场，以避免分支间切换时的影响。
2. 解决冲突
当同一个文件的内容在两个分支中不同时，两个分支各自分别有新的提交
因此，git无法执行“快速合并”，只能试图把各自的修改合并，但这种合并可能会用冲突。
git status可告诉我们冲突的文件。
无法自动合并分支时必须手动解决冲突后再提交。
解决冲突就是把git合并失败的内容手动编辑为我们希望的内容再提交。
冲突解决后
git log --graph --pretty=oneline --abbrev-commit 查看图形化的分支合并情况
3. 分支管理策略
合并分支时，git会优先使用“Fast forward”模式，但此模式下删除分支后会丢掉分支信息。
git merge --no-ff -m “描述信息” name 普通模式合并指定分支name到当前分支
加上–no-ff参数强制禁用该模式，这种合并保留了指定分支name的进度，git也会在merge时生成一个新的commit，这样就可用git log从分支历史上看出分支信息。
分支策略：
1）master分支应是稳定的，即仅用来发布新版本，平时不能在上面干活；
2）干活都在另一分支（如dev分支）上，即dev分支是不稳定的。要发布新版本时再把dev合并到master上，在master上发布新版本。
4. Bug分支
在你需要创建一个分支来修复bug，而你在dev上进行了一半的工作还无法提交时，可以用git stash暂存现场，等之后恢复现场后继续工作。
此时用git status查看工作区，就是干净的（除非有未被Git管理的文件），因此可以放心地创建分支来修复bug。
步骤：
1）确定在哪个分支修复bug，从该分支创建临时分支（假定要再master分支上修复）
2）在临时分支上修复bug并提交。
3）完成后切换到master分支并合并，最后删除临时分支。
Bug修复后，切换到dev分支，由于dev是早期从master中分出来的，此时dev上此bug还存在。
接下来先还原刚刚的工作现场，再修复dev上的bug。
还原现场：
git status查看时工作区是干净的，用git stash list 查看会发现工作现场还在。
恢复暂存现场有两种方法：
① 先 git stash apply 恢复（恢复后stash内容并不删除）
或用git stash apply stash@{1} 恢复指定的stash如stash@{1}(默认使用最近的,即stash@{0})
再git stash drop删除暂存内容
② git stash pop 恢复地同时也删除了stash内容
git stash不能将未被追踪的文件(untracked file)压栈,也就是从未被git add过的文件，在git stash之前一定要用git status确认没有Untracked files。
修复bug：
要在dev上修复同样的bug，只需把之前修复bug的那次提交（459ae65）所做的修改复制到dev（不是把整个master分支merge过来）。
在dev分支上git cherry-pick 459ae65 ，Git自动为dev做一次提交但这次的commit id不同于master 的那次。
5. Feature分支
为了不影响主分支，在开发新功能时，新建一个feature分支，在上面开发，完成后合并、再删除该分支。
git branch -d feature 删除分支
若此新建分支未合并就执行此命令，需要git branch -D feature强行删除。
6. 多人协作
git remote 或 git remote -v 查看远程库（默认名称是origin）信息
(后者查看的信息更详细，显示了抓取和推送的origin地址。若无推送权限，就看不到push地址)
git remote rm origin 删除指定地远程库
git push origin --delete name 删除远程name分支
推送分支：
git push origin name 推送指定本地分支name到远程库对应的远程分支
本地分支并不一定都要把往远程推送：
master分支是主分支，要时刻与远程同步；
dev分支是开发分支，每个成员都要在上面工作，也要与远程同步；
而bug分支只用于在本地修复bug，不必推到远程；
feature分支是否推到远程取决于你们是否合作在上面开发。
抓取分支：
多人协作时，甲可在另一台电脑（要把SSH Key添加到Github）或同一台电脑另一个目录克隆你的master分支：
git clone git@github.com:username/RepositoryName.git 克隆远程库到本地
默认情况下甲只能看到本地的master分支。
若甲要在dev分支上开发，就必须创建远程origin的dev分支到本地：
git checkout -b dev origin/dev 创建本地dev分支
然后他就可以在dev上继续修改并提交，时不时地把dev分支push到远程。
甲已经向origin/dev分支推送了他的提交，若恰巧你对同一文件做了修改并试图推送，此时若出现冲突：
git branch --set-upstream-to=origin/dev dev 设置本地dev分支与远程origin/dev分支的链接
再 git pull 把最新提交从origin/dev抓下来，在本地合并后再推送。
7. Rebase
git rebase 把本地未推送的分叉提交历史“整理“成直线
优点：看上去更直观
缺点：本地的分支提交已经被修改
（四）标签管理
Git的tag其实就是指向某个commit的指针（与分支相似，但分支可移动而tag不能动），它总是和某个commit挂钩，创建和删除tag都很快。
1. 创建标签
（先切换到需要打tag的分支上）
git tag name 创建标签（默认是打在最新提交的commit上，即HEAD）
git tag name commit_id 在指定commit id上打标签
git tag -a tagname -m “提示说明” commit_id 创建附带说明的标签
git log --pretty=oneline --abbrev-commit 查找历史提交的commit id（前7位即可）
git tag 查看所有标签(标签是按照tag的版本顺序排列，并非tag的时间顺序)
git show tagname 查看某标签信息（tagname为标签名）
注意：若被标记的commit既出现在master，又出现在dev，则这两个分支上都可看到这个标签。
2. 操作标签
git push origin tagname 推送某标签到远程
git push origin --tags 一次性推送全部未推送到远程的本地标签
git tag -d tagname 删除本地某标签
（创建的标签只存储在本地，不会自动推送到远程，所以打错的标签可在本地安全删除）
git push origin :refs/tags/tagname 删除远程某标签
（删除已推送tag时先删除本地，再删除远程，完成后可登录GitHub从远程库查看是否已经删除）
git fetch origin tag tagname 获取远程某标签（远程存在而本地不存在）
（五）使用Gitee
git remote add remotename git@gittee.com:username/repository.git
关联gitee的remotename远程库的repository仓库
一个本地库可关联多个远程库，但要用不同名称来标识不同的远程库
git remote -v 查看远程库信息
git remote rm remotename 删除远程库（名为remotename）
git push remotename branch 推送本地branch分支到远程库remotename
（六）自定义Git
配置git显示颜色或字体：
git config --global color.ui true 启用默认颜色设置
git config --global color.ui false 关闭默认颜色设置
也可针对具体命令进行设置，如color.branch ，color.diff等。
字体可用ui ，bold等。
1. 忽略特殊文件
编写.gitignore文件，将要忽略的文件放入.gitignore文件中，git就会自动忽略它们。
.gitignore文件本身要放到版本库里，并且可对它做版本管理。
忽略文件的原则：
1） 忽略OS自动生成的文件，如缩略图等；
2） 忽略编译生成的中间文件、可执行文件等（即通过一个文件自动生成的其他文件）；
3） 忽略自己的带有敏感信息的配置文件，如存放口令的配置文件。
git check-ignore -v filename 检查.gitignore文件书写是否有误
如：.gitignore文件期望忽略.class文件
对App.class执行该命令，若无输出，说明.gitignore没写对；若输出.gitignore:2*.class App.class，则设置正确。
2. 配置别名
git config --global alias.<简写名> <命令名> 简化命令名
git config --global --unset alias.<简写名> 删除别名
如： git log -1 显示最后一次提交信息
git config --global alias.last ‘log -1’ 之后，执行git last即可显示最后一次的提交
–global参数是全局参数，即这个命令在这台电脑的所有Git仓库下均有用，若不加此参数，只针对当前仓库起作用
配置文件：
每个仓库 的git配置文件都放在.git/config文件中，可用cat .git/config查看其内容。
（ 配置的别名就在[alias]后面，要删除别名，直接把对应的行删掉即可，也可用git config --global --unset alias.<简写名> ）
当前用户 的git配置文件放在用户主目录（C:/users/计算机名）下的隐藏文件.gitconfig中。配置别名也可直接修改这个文件，若改错了，可以删掉文件重新通过命令配置。
注意：查看用户配置信息可用 git config --global --list
查看当前仓库配置git config --local --list
用户的global配置在用户主目录下的.gitcongig文件中，仓库的.git/config只存当前仓库的本地配置。
来源：CSDN
作者：Candy_Editor
链接：https://blog.csdn.net/Candy_Editor/article/details/104399415