-
- 分支的本质
master指向的是提交
HEAD是指向当前的分支，当前在哪个分支就指向哪个分支
第二张图上我们可以看到创建了dev的分支，当我们切换到dev分支的时候HEAD就会指向dev
当我们进入.git文件夹查看HEAD的内容的时候可以看到，所处分支不同内部的文件指向就不同。
master分支
dev2分支
git的分支与svn不同，svn是整体拷贝一份分支，git用的是指针。
如果dev发生修改提交，dev的版本就会向后移动。
在master分支上如果合并就会出现下面的图
-
- 分支的冲突
我们在dev2分支里面修改A.txt文件添加一行 update by dev2后提交
我们在master分支里面修改A.txt文件同时添加一行 update by master后提交
合并时候我们发现出现冲突
<<<<<<<<<<<HEAD是当前指向的分支所修改
>>>>>>>>>>dev2是dev2分支修改
我们需要手工合并。修改后报了master的内容
我们可以通过图形来查看冲突的提交日志。
git log --graph
- Git stash
1 当正在dev分支上开发某个项目，这时项目中出现一个bug，需要紧急修复，但是正在开发的内容只是完成一半，还不想提交，这时可以用git stash命令将修改的内容保存至堆栈区，然后顺利切换到hotfix分支进行bug修复，修复完成后，再次切回到dev分支，从堆栈中恢复刚刚保存的内容。
2 由于疏忽，本应该在dev分支开发的内容，却在master上进行了开发，需要重新切回到dev分支上进行开发，可以用git stash将内容保存至堆栈中，切回到dev分支后，再次恢复内容即可。
总的来说，git stash命令的作用就是将目前还不想提交的但是已经修改的内容进行保存至堆栈中，后续可以在某个分支上恢复出堆栈中的内容。这也就是说，stash中的内容不仅仅可以恢复到原先开发的分支，也可以恢复到其他任意指定的分支上。git stash作用的范围包括工作区和暂存区中的内容，也就是说没有提交的内容都会保存至堆栈中。
-
- git stash
我们在master分支修改A.txt添加一行
这时我们要切换dev2分支
我们发现会提示错误，git建议我们先提交或者stash修改的内容再切换
我们执行
git stash
会先把修改的内容做保存然后我们就可以切换到其他的分支
列出stash保存的所有修改
我们切换回master分支执行，我们能看到上次保存的操作
git stash list
我们同样也可以再次修改文件去做stash，这样就会产生2条保存的记录
我们可以将stash过的修改恢复出来。通过pop取出最近的恢复并且删除stash中的修改
git stash pop
如果两次pop由于提一次没有做提交则会报错，所以我们应该把第一次pop的提交，在pop第二次的。
- 分支管理策略
git 的分支整体预览图如下：
从上图可以看到主要包含下面几个分支：
master：git默认主分支（这里不作操作）。
stable：稳定分支，替代master，主要用来版本发布。
develop：日常开发分支，该分支正常保存了开发的最新代码。
feature：具体的功能开发分支，只与 develop 分支交互。
release：release 分支可以认为是 stable分支的未测试版。比如说某一期的功能全部开发完成，那么就将 develop 分支合并到 release分支，测试没有问题并且到了发布日期就合并到 stable分支，进行发布。
bugfix：线上 bug 修复分支。
-
- 主分支
因为master分支我们不作操作，所以针对stable和develop这两个主分支来讲解。
stable分支：用来发布，管理着多个稳定的版本。
develop分支：就是我们日常开发的分支。
使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题后，则将 develop 分支的代码合并到 stable分支并发布。
-
- 辅助分支
通过这些分支，我们可以做到：团队成员之间并行开发，增加新功能更加容易，可以同时进行开发和版本发布、线上bug修复等。
-
-
- Feature分支
-
feature 分支用来开发具体的功能，一般基于develop分支，最后完成功能后再合并到develop分支。
比如，目前我们针对develop分支来做功能开发，在开发的过程中会有紧急需求需要开发，且在本次版本发布时间之前要能测试完成。我们可以基于之前稳定版本另开一个feature分支来做紧急需求的开发，发布并进行测试，完成之后再合并到develop分支上。
-
-
- release分支
-
release分支作为预发布分支，release 分支从 develop 分支 fork 出来，最终会合并到 develop 分支和 stable 分支，合并到 stable分支上就是可以发布的代码了。
为什么我从develop分支fork出来，还要合并到develop分支中呢？因为我们在release分支上难免会有bug产生，修复bug也是在release分支上，所以必须要合并到develop分支。
-
-
- bugfix分支
-
bugfix 分支用来修复线上bug。当线上代码出现 bug 时，我们基于 stable 分支开一个bugfix分支，修复 bug之后再将 bugfix分支合并到stable分支并进行发布，同时develop 分支作为最新最全的代码分支，bugfix分支也需要合并到 develop 分支上去。
- GitHub注册创建仓库
GitHub是一个面向开源及私有软件项目的托管平台，因为只支持git 作为唯一的版本库格式进行托管，故名GitHub。
-
- 仓库注册
GitHub官网：https://github.com/
-
- 仓库创建
验证邮箱
邮箱验证完毕，创建仓库
点击创建仓库，私有仓库目前也公开了，不过只能最多三个协作者。
- 推送本地仓库到远程
删除之前的仓库中的所有内容，从新建库，同时创建一个A.txt文件。
-
- 修改本地仓库用户名
为了本地演示多个用户操作，我们把仓库local的级别的用户设置一下
$ git config --local user.name '鲁智深'
$ git config --local user.mail ''
-
- push命令
github已创建空仓https://github.com/txjava-teach/txjava-code.git，本地库要上传并与之关联：
git remote add origin https://github.com/txjava-teach/txjava-code.git
添加后，远程库的名字就是origin，这是Git默认的名字，也可以改成别的，但是origin这个名字⼀看就知道是远程库。下一步，就可以把本地库的所有内容推送到远程库上:
然后推送本地库的文件。
git push -u origin master
第⼀次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master 分支关联起来
只要本地作了提交，就可以通过命令:
git push origin master
把本地master分支的最新修改推送至GitHub
查看远程仓库
git remote show
origin相当于远程仓库的链接别名
查看远程仓库明细
git remote show origin
上面命令展示了origin的详细信息，
远程拉取的url
push推送的url
头指针指向的master分支，同时远程分支是被追踪的状态
本地master分支被配置成git pull会拉取并且合并远程master
本地master分支配置成git push推送远程master
-
- 远程分支查看
origin master关联的是远程的master分支，用于追踪远程分支的状态
查看远程分支
git branch -a
我们加上参数v可以查看本地分支和远程分支的最后提交
git branch -av
我们修改A.txt文件
我们通过git status可以看到我们master分支和远程分支origin/master都是最新的。
此时我们提交我们的修改后在查看git status，我们可以发现我们的本地master分支领先了1次提交。
从分支的详细信息中我们可以看到远程分支的提交版本和master的提交版本不同，本地领先了。
此刻我们把本次修改推送到远程，远程和本地便保持了版本的同步
- git多人协作
- 项目克隆
我们可以把远程项目克隆到本地形成一个本地的仓库
git clone https://github.com/txjava-teach/txjava-code.git
我们可以发现克隆下来的仓库和远程仓库的名字一致
进入仓库可以看到.git的配置文件和远程代码
.git中的配置可以看到目前的分支为master，远程别名是origin，关联合并的是远程分支的master
注意：我们也可以克隆远程项目自己定义仓库名字
git clone https://github.com/txjava-teach/txjava-code.git testGit2
-
- 多人协作
- 创建林冲仓库
- 多人协作
克隆远程仓库命名testGit1.
指定本地仓库级别的用户名和邮箱
git config --local user.name '林冲'
git config --local user.email ''
-
-
- 协作处理
-
在testGit中通过鲁智深添加文件并且推送到远程
在testGit1仓库中林冲查看远程状态发现已经过期。
此时林冲应该从远程仓库来更新拉取
fast-forward表示不需要手工处理冲突直接合并。
-
-
- 冲突处理
-
当两个人修改同一个文件的同一行的时候就会发生冲突
我们使用鲁智深修改B.txt内容后
提交并且推送到远程
此刻林冲也修改B.txt内容：
我们提交并且推送远程的时候发现出现冲突，推送失败
此刻git要求我们先拉取更新
我提示中我们发现拉取成功，但是自动合并失败。git建议我们修改冲突后提交。
我们可以修改冲突，此时和svn是一样的。我们保留林冲的
推送到远程
搞定
-
- 分支推送协作
创建develop分支
我们发现git push无法把develop推送到远程。
执行下面的命令，这就是把本地的分支推送到远程分支。
git push --set-upstream origin develop
我们可以看到远程分支已经推送。
同时本地也关联了远程develop分支
除此之外我们可以使用下面命令完成远程分支推送
git push -u origin 分支名
我们创建分支，并且把分支推送到远程
分支查看
-
- 分支拉取协作
由于鲁智深已经推送，我们使用林冲的账户来拉取，我们可以看到新建立了分支
但是我们发现有远程分支，但是没有本地的develop分支。
这时我们可以创建本地的develop分支，此刻我们也可以修改本地分支的名字
git checkout -b develop origin/develop
我们已经创建分支并且切换到develop上，而且该分支和远程分支develop关联。
查看
我们还可以使用另一种方式本地分支的追踪，但是必须要先git pull
git checkout --track origin/feature
-
- 远程分支的删除
我们在鲁智深仓库删除Feature分支，删除之后远程的Feature分支关联还在。
我们也可以删除对应的远程分支
git push origin --delete feature
当我们通过另一个用户来查看本地对应的远程分支的时候可以看到远程分支的变化。
查看origin远程对应的分支
git remote prune origin
- tag标签远程管理
- git 标签 tag管理
新建标签，标签有两种:轻量级标签(lightweight) 与带有附注标签(annotated)
创建一个轻量级标签。
创建标签记在HEAD指针所指向的提交点创建tag（就是当前所在分支）
git tag v1.0.1
创建一个带有附注的标签
git tag -a v1.0.2 -m 'release version'
标签不依赖于分支。
.删除标签
git tag -d tag_ name
-
- 标签推送
我们前面已经介绍过标签的创建
我们创建3个标签
把多个标签推送到远程
git push origin 标签1 标签2……
GitHub上可以看到标签已经推送，标签代码可以下载。
可以把所有标签推送到远程。
git push origin --tag
-
- 标签拉取
git pull
我们通过林冲用户来拉取
-
- 删除远程分支
git push origin :refs/tags/标签名
远程标签被删除
同时也可以
git push origin --delete tag 标签1 标签2…
远程标签删除后本地标签不会消失，我们可以手动删除本地标签
-
- 标签检出
git checkout -b <branchName> <tagName>
我们创建tx_master_v1.0标签并且推送到远程
然后我们通过此标签来检出分支
git checkout -b myfeature tx_master_v1.0
但是次分支这是本地分支，我们可以推送到远程
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/rfx/36523.html