Git使用手册
Git系统学习，使用手册。
Git 分布式版本控制系统 注：CVS及SVN集中式版本控制系统
创建版本库repository
里面每个文件的修改、删除都可以跟踪，可以还原
利用git init将目录编程Git仓库，.git文件是Git来跟踪管理版本库
添加文件到Git仓库，分两步：
- 使用命令
git add <file>，注意，可反复多次使用，添加多个文件； - 使用命令
git commit -m <message>，完成。
git status命令可以让我们时刻掌握仓库当前的状态git diff顾名思义就是查看difference
git log命令显示从最近到最远的提交日志
Head表示当前版本 版本号由sha1计算而得（可记住版本号reflog永久回退此版本）
git reset --hard XXXX
仓库里把每次修改以版本号记录下来，回退某版本仅为将HEAD指向其。
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。穿梭前，用
git log可以查看提交历史，以便确定要回退到哪个版本。要重返未来，用
git reflog查看命令历史，以便确定要回到未来的哪个版本。
工作区和暂存区
工作区Working Directory -> git-learn目录
版本库Repository -> .git
.git
暂存区stage 分支master，指向master的第一个指针HEAD
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
Untracked files 未添加至暂存区stage
执行git add readme.txt & LICENSE后
执行git commit 提交至分支master
管理修改
Git跟踪并管理的是修改，而非文件。
git commit只负责把暂存区的修改提交了
git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别
撤销修改
git checkout -- file可以丢弃工作区的修改
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令
git checkout -- file。场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令
git reset HEAD <file>，就回到了场景1，第二步按场景1操作。场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。
删除文件
一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：
删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本： git checkout -- test.txt
远程仓库
git push -u origin master 把本地库的所有内容推送到远程库上
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
git push origin master 把本地库的所有内容推送到远程库上
- 要关联一个远程库，使用命令
git remote add origin git@server-name:path/repo-name.git； - 关联后，使用命令
git push -u origin master第一次推送master分支的所有内容； - 此后，每次本地提交后，只要有必要，就可以使用命令
git push origin master推送最新修改；
从远程库克隆
1 | git clone git@github.com:murraynizeyu/git-learn.git |
分支管理
主分支：master与develop
master：分支代表项目处于可发布的状态
develop：需要开发新功能时从develop分支拉出fb-function分支
Feature branches：这种分支和我们程序员日常开发最为密切，称作功能分支。
必须从develop分支创建，完成后合并回develop分支。
Release branches：这个分支用来分布新版本。从develop分支创建，完成后合并回develop与master分支。
Hotfix branches：这个分支主要为修复线上特别紧急的bug准备的。必须从master分支创建，完成后合并回develop与master分支。
总结一下
我们创建dev分支，然后切换到dev分支：git switch -c dev
通过git branch查看当前分支
HEAD指向当前commit版本上传的位置
我们把dev分支的工作成果合并到master分支上：git merge dev
git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。
合并完成后，就可以放心地删除dev分支了：git branch -d dev
直接切换到已有的master分支 git switch master
| 功能 | 命令 |
|---|---|
| 查看分支 | git branch |
| 创建分支 | git branch <name> |
| 切换分支 | git switch <name> |
| 创建+切换分支 | git switch -c <name> |
| 合并某分支到当前分支 | git merge <name> |
| 删除分支 | git branch -d <name> |
解决冲突
准备新的feature1分支，继续我们的新分支开发
Git还会自动提示我们当前master分支比远程的master分支要超前1个提交
回到master分支修改readme.txt再次提交 注意产生冲突
通过对readme.txt文件进行修改解决冲突后再上传
1 | git log --graph --pretty=oneline --abbrev-commit 查看分支合并情况 |
分支管理策略
Bug分支
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场
git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；在master分支上修复的bug，想要合并到当前dev分支，可以用
git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。
Feature分支
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。
就地销毁git branch -D feature-v
多人协作
推送分支
显示抓取和推送的origin地址 git remote -v
推送本地到远程库 git push origin main
master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；- bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
- feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
抓取分支
从本地推送分支，使用
git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；在本地创建和远程分支对应的分支，使用
git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；建立本地分支和远程分支的关联，使用
git branch --set-upstream branch-name origin/branch-name；从远程抓取分支，使用
git pull，如果有冲突，要先处理冲突。
Rebase
