Git分支管理
转载
https://www.cnblogs.com/chechen/p/9950798.html
git 基础命令
添加相关
git stutas #查看工作区状态
git add #将工作区修改或新增的文件添加到暂存区
git commit -m"message" #提交暂存区的文件
git cherry-pick <commit_id> #如果在dev分支下提交了某些文件（commit_id=c0e345），需要将这次提交的文件合并到master分支，则用git checkout master切换到master分支，再使用git cherry-pick c0e345 将这些在dev分支修改的文件合并到master分支上
文件比较
git diff HEAD -- <file> #将file文件的的工作区和最新版本的内容进行比较
git diff <file> #如果文件当前在暂存区，则将工作区和暂存区进行对比。如果当前文件未添加到暂存区，则对比工作区和版本库的内容
日志
git log # 显示从最近到最远的提交日志
git log --pretty=oneline #将日志显示为单行
git reflog #显示日志 id显示为前七位
git log --graph # 显示分支日志图
版本回退
git reset --hard <version_id> #回退到版本号为version_id的版本，此时HEAD指针会移动到回退的那个版本
撤销修改
git checkout -- <file> #把file文件在工作区的修改全部撤销，有两种情况：
#一、如果该文件已添加到暂存区，后有在工作区做了修改，则执行该命令后该文件回退到暂存区的状态
#二、如果该文件自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
# 注意该命令中的 -- 必须要，否则就变成了切换分支
如果误删了某个文件file，可以用个git checkout -- file 将文件恢复回来且为版本库最新版本
git reset HEAD <file> #可以把暂存区的修改撤销掉（unstage），重新放回工作区
远程仓库
git remote add origin <remote_git_url> #将本地已有的仓库与远程仓库关联并命名为origin
git remote remove origin #删除本地仓库关联的远程仓库origin
git push -u origin <branch> # 将本地仓库branch分支推送到远程仓库,由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令不用带-u。
git push origin <branch>
git clone git@github.com:dengyw15/gitlearn.git #clone远程仓库到本地
git pull origin <branch> #当远程仓库内容有修改时，需要将远程仓库的修改拉取到本地
git remote -v #远程仓库的信息
分支管理
git branch -b <branch_name> # 创建并切换到branch_name分支，与git switch -c <branch_name>作用一致，相当于以下两条命令：
# git branch <branch_name> #切换分支，也可用git switch <branch_name>
# git checkout <branch_name>
git branch -d <branch_name> # 删除branch_name分支，如果该分支上还有代码为提交，可以使用-D参数强制删除
git merge <branch_name> # 如果当前分支为master， git merge dev命令则是将dev分支上面的修改合并到master分支上
git branch --set-upstream-to=origin/dev dev # 建立本地dev分支与远程dev分支的连接
# 通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
git merge --no-ff -m "merge with no-ff" dev #-m参数后跟合并的描述信息
分支策略
在日常开发中，我们对分支的管理应该遵循几个原则：
1、master分支应该是非常稳定的，仅仅用来发布新版本，平时开发不用这个分支
2、开发都在dev分支上，dev分支是不稳定的，比如发布1.0版本的时候，dev分支的代码合并到master分支上，通过master分支发布生产版本
3、项目成员可以创建自己的分支，完成自己代码的开发，功能开发完成后合并到dev分支上。
最终的分支如下图：
image.png
bug分支
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；
在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。
feature分支
开发一个新功能，最好新建一个分支。待功能开发完成后，切换到原分支上，并将代码进行合并。
如果要丢弃一个没有被合并过代码的分支，可以使用git branch -D <branch_name>强行删除
冲突解决
DYW@DESKTOP-R7AOTTS MINGW64 /f/gitlearn (master)
$ git merge dev # 合并dev分支
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
DYW@DESKTOP-R7AOTTS MINGW64 /f/gitlearn (master|MERGING)
$ vi readme.txt # 手动解决冲突
DYW@DESKTOP-R7AOTTS MINGW64 /f/gitlearn (master|MERGING)
$ git add readme.txt
DYW@DESKTOP-R7AOTTS MINGW64 /f/gitlearn (master|MERGING)
$ git commit -m"conflict readme.txt" # 提交冲突
[master 208212c] conflict readme.txt
DYW@DESKTOP-R7AOTTS MINGW64 /f/gitlearn (master)
标签管理
发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。commit号是一串乱七八糟的字符，通过tag可以更直观的展示。
标签创建
首先切换到要打标签的分支上面
git tag <name> #打新标签，默认标签是打在最新提交的commit上的
git tag <name> <commit_id> # 给历史提交的commit打标签
git tag -a <name> -m <message> <commit_id> #创建带有说明信息的标签，name为标签名， message为标签说明
git tag #查看所有标签
git show <tag_name> #显示某个tag的具体信息
示例：
DYW@NBAIDENGYW01 MINGW64 /h/lab/gitlearn (master)
$ git tag -a v1.0 -m"version 1.0 release"
DYW@NBAIDENGYW01 MINGW64 /h/lab/gitlearn (master)
$ git tag
v1.0
DYW@NBAIDENGYW01 MINGW64 /h/lab/gitlearn (master)
$ git show v1.0
tag v1.0
Tagger: dengyw15 <ywdenguestc@gmail.com>
Date: Tue Feb 4 12:09:27 2020 +0800
version 1.0 release
commit f27cf058c410d87e7c29658dcb95690a11e670fd (HEAD -> master, tag: v1.0, origin/dev, dev)
Author: dengyw15 <ywdenguestc@gmail.com>
Date: Tue Feb 4 11:49:50 2020 +0800
add local dev
diff --git a/readme.txt b/readme.txt
index eb5a860..50aa283 100644
--- a/readme.txt
+++ b/readme.txt
@@ -2,3 +2,4 @@ this is a readme text.
now add a new line
dfdfsdf
bug issue-101
+local dev
标签管理
git tag -d <name> #本地删除标签名为name的标签
git push origin <name> #推送标签名为name的标签到远程仓库
git push origin --tags # 一次性推送全部尚未推送到远程仓库的标签
如果标签已经推送到远程仓库，需要删除该标签，需要两步：
git tag -d <name> #本地先删除该标签
git push origin :refs/tags/<name> # 删除远程标签
示例：
DYW@NBAIDENGYW01 MINGW64 /h/lab/gitlearn (master)
$ git tag
v0.9
v1.0
DYW@NBAIDENGYW01 MINGW64 /h/lab/gitlearn (master)
$ git push origin v1.0
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 165 bytes | 55.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To github.com:dengyw15/gitlearn.git
* [new tag] v1.0 -> v1.0
DYW@NBAIDENGYW01 MINGW64 /h/lab/gitlearn (master)
$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To github.com:dengyw15/gitlearn.git
* [new tag] show -> show
* [new tag] v0.9 -> v0.9
DYW@NBAIDENGYW01 MINGW64 /h/lab/gitlearn (master)
$ git tag -d v0.9
Deleted tag 'v0.9' (was b356c28)
DYW@NBAIDENGYW01 MINGW64 /h/lab/gitlearn (master)
$ git push origin :refs/tags/v0.9
To github.com:dengyw15/gitlearn.git
- [deleted] v0.9
其他操作
git stash #将当前工作现场“隐藏”起来，等以后可以回复现场继续工作。 比如当某项工作进行到一半，需要进行其他bug修复，此时可以用该命令将当前工作现场先隐藏起来，当该bug修复完成后可以通过下述命令对现场进行恢复
git stash list #查看当前隐藏的工作现场，如：
DYW@NBAIDENGYW01 MINGW64 /h/lab/gitlearn (dev)
$ git stash list
stash@{0}: WIP on dev: e0a1af3 Merge branch 'master' of github.com:dengyw15/gitlearn
要恢复工作现场有以下两种方法：
1.git stash apply #恢复现场后，stash内容不会被删除，需要使用git stash drop 来手动删除
git stash apply stash@{0} #可以恢复置顶的stash
2.git stash pop #恢复现场后会自动删除stash内容
自定义Git
忽略特殊文件
在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。
不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore
忽略文件的原则是：
忽略操作系统自动生成的文件，比如缩略图等；
忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。
git add -f User.class # 如果在ignore文件中忽略了class后缀的文件，而实际需要将a.class添加到版本管理，则用该命令强制添加
git check-ignore -v User.class #检查ignore文件中是哪条配置忽略了User.class
配置别名
多人协作工作模式
- 如果远程仓库已有工程，则通过git clone <url> 将工程克隆下来。
- 通过git push origin <branch> 推送本地修改到远程仓库
- 如果推送失败，通过git pull origin <branch> 将远程仓库的代码拉取下来
- 如果拉取代码出现冲突，则在本地手工解决冲突，并在本地提交
- 没有冲突或冲突解决后，再git push origin <branch> 将修改推送到远程仓库
如果git pull时提示no tracking information，则说明本地和远程分支的链接还没有建立，则通过git branch --set-upstream-to=origin/<branch_name> <branch_name>建立链接
