《Git 教程》-- 廖雪峰笔记_git教程-优快云博客

本文链接：https://blog.youkuaiyun.com/u012104827/article/details/106767723

设置用户名和邮箱
git config --global user.name "Your Name"
git config --global user.email "email@example.com"
注意：git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git版本库都会使用这个配置，当然也可以对某个版本库指定不同的用户名和Email地址
创建空的版本库（empty Git repository）
git init
添加文件到暂存区
git add <file>
推送到版本库
git commit -m <message>
初始化一个Git版本库，使用git init命令
添加文件到Git版本库，分两步：
使用命令git add <file>，注意，可反复多次使用，添加多个文件，实际上就是把文件修改添加到暂存区
使用命令git commit -m <message>完成，实际上就是把暂存区的所有内容提交到当前分支
查看版本库当前的状态
git status
查看当前文件与版本库记录的文件的差异
git diff <file>
也可以写成下面这样
git diff <commit id>/HEAD -- <file>
这样比较灵活
查看日志记录
git log
注意：嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数
移动版本库的版本
git reset --hard HEAD^
上述语句为使版本库回退到上一个版本，上两个版本即HEAD^^
也可以写成下面这样
git reset --hard HEAD~1
上两个版本即HEAD~2
也可以指定版本库移动到某一个版本
git reset --hard <commit id>
<commit id>不用全部输入，只需要输入前7位即可
注意：在windows的cmd中，^是特殊符号，使用时需要用双引号包住，如"^"
查看版本库的命令执行历史
git reflog
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard <commit id>
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本
为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件
每次修改，如果不用git add到暂存区，那就不会加入到git commit中
复原工作区的修改
git checkout -- <file>
这里有两种情况：
一种是文件自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态
一种是文件已经添加到暂存区后，又作了修改，现在撤销修改就回到添加到暂存区后的状态
总之，就是让这个文件回到最近一次git commit或git add时的状态
命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令
把暂存区的修改回退到工作区，即将暂存区变回跟版本库一样，复原暂存区的修改
git reset <commit id>/HEAD <file>
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- <file>
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD <file>，就回到了场景1，第二步按场景1操作
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库
删除版本库中的文件
git rm <file>
创建SSH Key（在windows下需要打开Git Bash）
ssh-keygen -t rsa -C "youremail@example.com"
你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。如果一切顺利的话，可以在用户主目录里找到ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人
为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送
关联一个远程库
git remote add <origin name> git@server-name:path/repo-name.git
把本地库的内容推送到远程
git push <origin name> master
实际上是把当前分支master推送到远程，如果远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令，例如
git push -u <origin name> master
克隆远程库到本地
git clone <origin address>
Git支持多种协议，包括https，但通过ssh支持的原生Git协议速度最快
创建并切换分支
git checkout -b <branch name>
也可以分成两步走
创建分支
git branch <branch name>
切换分支
git checkout <branch name>
查看当前分支
git branch
git branch命令会列出所有分支，当前分支前面会标一个*号
切换当前分支
git checkout <branch name>
合并指定分支到当前分支
git merge <branch name>
删除指定分支
git branch -d <branch name>
若分支没有被合并过，则
git branch -D <branch name>
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交
查看带分支合并的日志记录图
git log --graph --pretty=oneline --abbrev-commit
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息
git merge --no-ff -m <message> <branch name>
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了
储藏当前工作现场
git stash
查看储藏工作现场列表
git stash list
恢复工作现场
git stash apply <stash list name>
删除储藏的工作现场列表
git stash drop <stash list name>
恢复并删除储藏的工作现场
git stash pop <stash list name>
查看远程仓库的信息
git remote
查看远程仓库的详细信息
git remote -v
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
git push <origin name> <branch name>
抓取分支（创建远程分支到本地）
git checkout -b <branch name> <origin name>/<branch name>
指定本地分支与远程分支的链接
git branch --set-upstream-to=<origin name>/<branch name> <branch name>
多人协作的工作模式通常是这样：
首先，可以试图用git push <origin name> <branch name>推送自己的修改
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并
如果合并有冲突，则解决冲突，并在本地提交
没有冲突或者解决掉冲突后，再用git push <origin name> <branch name>推送就能成功
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to=<origin name>/<branch name> <branch name>
这就是多人协作的工作模式，一旦熟悉了，就非常简单
rebase操作可以把本地未push的分叉提交历史整理成直线
rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比
git rebase
打标签
git tag <tag name>
指定打标签的commit id
git tag <tag name> <commit id>
创建带有说明的标签，用-a指定标签名，-m指定说明文字
git tab -a <tag name> -m <message> <commit id>
注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签
查看标签
git tag
注意，标签不是按时间顺序列出，而是按字母排序的
查看标签信息
git show <tag name>
删除标签
git tag -d <tag name>
如果标签已经推送到远程，先从本地删除
git tag -d <tag name>
再远程删除
git push <origin name> :refs/tags/<tag name>
推送标签到远程版本库
git push <origin name> <tag name>
一次性推送全部尚未推送到远程的本地标签
git push <origin name> --tags
删除已关联的远程库：
git remote rm <origin name>
忽略特殊文件
在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名或文件夹填进去，Git就会自动忽略这些文件或文件夹及其子文件
不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了
所有配置文件可以直接在线浏览：https://github.com/github/gitignore
忽略文件的原则是：
忽略操作系统自动生成的文件，比如缩略图等
忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件
忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件
添加已忽略的文件
git add -f <file>
检查忽略规则
git check-ignore -v <file>
技巧，优化log显示并简短为 git lg
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
分支开发应用示例
master分支，即主分支。任何项目都必须有个这个分支。对项目进行tag或发布版本等操作，都必须在该分支上进行
develop分支，即开发分支，从master分支上检出。团队成员一般不会直接更改该分支，而是分别从该分支检出自己的feature分支，开发完成后将feature分支上的改动merge回develop分支。同时release分支由此分支检出
release分支，即发布分支，从develop分支上检出。该分支用作发版前的测试，可进行简单的bug修复。如果bug修复比较复杂，可merge回develop分支后由其他分支进行bug修复。此分支测试完成后，需要同时merge到master和develop分支上
feature分支，即功能分支，从develop分支上检出。团队成员中每个人都维护一个自己的feature分支，并进行开发工作，开发完成后将此分支merge回develop分支。此分支一般用来开发新功能或进行项目维护等
fix分支，即补丁分支，由develop分支检出，用作bug修复，bug修复完成需merge回develop分支，并将其删除。所以该分支属于临时性分支
hotfix分支，即热补丁分支。和fix分支的区别在于，该分支由master分支检出，进行线上版本的bug修复，修复完成后merge回master分支，并merge到develop分支上，merge完成后也可以将其删除，也属于临时性分支