git实用开发文档
Posted weixin_43553755
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了git实用开发文档相关的知识,希望对你有一定的参考价值。
git使用开发文档
很多开发者工作一定年限后任然对git只是停留在基本使用层面。多人开发的时候,每次合并代码的时候都是忐忑,接下来一文帮组大家更深入的了解git的使用
文章目录
- git工作流
- git工作原理
- git常用命令
- git默认覆盖代码的情况
一、git工作流
git的工作流分为一下四种:
1.集中式工作流
和svn类似: 所有人都是用一个master分支;
2.功能分支工作流
都是基于master拉取一个分支进行开发,然后本地合并到master上
3.gitflow工作流
就是各个分支功能比较明确;
发布分支:master;
测试分支:test;
开发分支:develop;
临时开发分支1: feature1
临时开发分支2: feature2
临时开发分支3: feature4
4.Forking工作流
适用于开源项目,提供所有人能贡献代码;
二、git工作原理
svn等都是用集中式版本控制系统,git使用的是分布式版本控制系统;
集中式版本控制系统:在本地是没有库的,提交都必须要有网络才行
分布式版本控制系统:在本地有本地库,提交到本地有可以了,需要要的时候再提交到远程;
大致工作流程如下:
三、git常用命令
git clone、git add .、git commit -m''、git push、git merge 、git log、git branch、git checkout 分支、git branch -D 分支、git reset、git revert等常用的命令不在此介绍;
主要介绍一下工作上常用的一些场景
场景1: 当你开发一个功能进度一半的时候,需要到其他分支去开发其他的
git stash (推入到栈中)
git stash save 'message...'(添加注释)
git stash list // 查看保存列表
git stash pop(推出栈)
git stash pop stash@1 // 推出对应的栈中的保存
git stash clear 。 // 清楚所有栈中的保存
场景2: 当你上一个commit的保存信息发生错误的时候;需要修改之前的提交记录信息;或者还有一些文件忘了同时提交需要和上次提交一起
git commit --amend(进行编辑信息或者git commit --amend -m'xxxx'
四、git默认覆盖代码的情况
git的commit-id是根据SHA1加密的方式计算的40位的hash值;
只要创建test的分支的HEAD指针高于master当时的指针,master合并test的时候会把master
的指针直接指到39b830d07fc8e08f541e7cbf3391d2343d3adffb,就是Fast-forward模式;
如果此时master的指针也向前走了一个commit,那么这时合并test的时候就会产生冲突,解决冲突后再
commit一次,master指针继续向前走了一步;
我们常见的代码覆盖情况:
拿同一个分支上代码覆盖举例:合并代码解决冲突的时候选择自己的代码推到远程。例如:user1把代码合并到远程master后,此时HEAD指针指向commit-id1,这时候user2也改了相同的代码,把自己的代码合并到master,这时候HEAD指针指向commit-id2. commit-id2的指针在commit-id1之后,这时候当user1再提交代码的时候,他需要先pull一次,这时候pull下来的就是user2覆盖自己代码的情况。
我们正常开发的时候都是gitflow的情况,多功能分支开发。
master: 主分支;
test: 测试分支;
develop1: 开发分支1;
develop2: 开发分支2;
注意:如果是开发交叉性的功能需要去经常合并master到本地,尽可能减少本地开发分支develop1、develop2与master的版本差距。如果有冲突在本地合并冲突。不需要去合并测试分支,每次测试的时候直接test去merge develop1、develop2本地分支就可以了。develop1和develop2合并master,在本地解决冲突,这时候的指针高于master,直接合并到master就不会产生冲突;但开发者解决冲突的时候需要谨慎;
总结
只要理解了git的工作原理,就会避免在开发时犯一些错误。
以上是关于git实用开发文档的主要内容,如果未能解决你的问题,请参考以下文章