Git的正确使用姿势
程序员文章站
2022-03-01 22:57:27
...
1,Git教程
廖雪峰老师的Git教程
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000
一个成功的Git分支开发模型
https://blog.csdn.net/qq_34651940/article/details/51891767
《一个成功的Git分支模型》为什么是有害的
https://www.jianshu.com/p/748e4892871a
2,Git的正确使用姿势
开发部目前使用Git的问题
1,提交内容混乱
2,出现很多的合并导致的无疑义提交,例如 “Merge branch ‘some-branch’ of git://git.some.domain/repository/”
3,三个主分支之间的频繁合并工作和产生的无疑义的合并信息
解决办法如下
必须的默认配置
git config --global pull.rebase preserve #拉取并变基
直接在master(或dev)分支上开发的场景模拟
1,master分支跟踪远端
2,一天的开发过程中常规性的commit多次
3,下班前对commit信息进行合并:git rebase -i origin/master #合并本地commit
4,pull #拉取并变基(有冲突就解决)
5,push (也可以先push,如果push不了,就pull后再push(有冲突就解决后push))
正宗的:在本地的工作分支上进行开发的场景模拟
1,master分支跟踪远端
2,签出本地工作分支f1
3,一天的开发过程中常规性的commit
4,下班前对commit信息进行合并:rebase -i master (编辑合并后的提交信息)
5,切换到master分支,merge
6,pull #拉取并变基(有冲突就解决)
7,push (也可以先push,如果push不了,就pull后再push(有冲突就解决后push))
强调:rebase只能用在本地分支
建议的Git工作模式规则
1,工作分支一定独立出来-->使得可以整理出有意义的Commit信息
2,使用rebase替代merge-->减少无意义的合并信息
3,使用master分支作为开发分支-->减少dev分支往master分支的合并工作
4,用release分支作为发布分支,发布前打tag-->减少分支的合并工作
5,每次测试都要产生新的release分支-->减少分支的合并工作
Alias
git rebase -i origin/master #合并本地commit
git config --global alias.tidy "rebase -i @{upstream}" #配置快捷方式
git config --global pull.rebase preserve #拉取并变基
3,Git基本命令
基本命令
先初始化再关联远程仓库
git init
git remote add origin https://github.com/xxxx.git
先克隆
git clone https://github.com/xxxx.git
本地添加和提交
git add README.md
git commit -m "first commit"
日志
git log --graph --pretty=oneline --abbrev-commit
远程仓库
git push -u origin master
git pull origin master --refusing to merge unrelated histories
分支
git branch
git checkout -b dev 从当前分支创建分支dev,并切换到dev分支
git checkout dev 切换到dev分支
关于Git分支和常用命令
我们clone代码到本地之后会保存成两个分支
本地分支和远程跟踪分支(origin/master)
我们所有的修改都会在本地分支中进行
Fetch操作会更新远程跟踪分支
Merge会将远程更新分支中的修改合并到本地分支
Pull = Fetch + Merge
Push会把本地分支推送到服务器,如果成功或做一次Fetch更新本地的远程跟踪分支使保持一致
关于差异比较
在Git的理念中本地分支和远程分支地位是一样的,所以在SVN中跟服务器的比较功能在Git中没有
执行git diff 的时候是工作空间和本地分支比较
Commit之后,工作空间和本地分支就没有区别了,git diff就没有结果
当远程分支Fetch后可以用git diff origin/master比较工作空间和远程分支的差异
标准代码提交流程
1,将修改的地方全部Commit到本地仓库,如果你还不想推送到远程仓库可以不用
2,Fetch远程代码到本地的跟踪分支
3,Merge本地仓库代码到工作空间,工作空间还有修改没有Commit时不能合并
4,Push本地仓库代码到远程服务器
冲突的解决
Merge后如果出现冲突,冲突的文件会被修改
方法一:
这个时候,重新编辑这个文件解决冲突,再Commit,再Push就会用本地的文件覆盖服务器的文件
方法二:
如果想撤销之前的Commit可以用一下命令
git log
git reset --hard commit_id
撤销后再Merge,再重新开发再Push
用远程代码强制覆盖本地代码
git fetch --all
git reset --hard origin/master
git rm file 会将文件从暂存区与磁盘上删除
廖雪峰老师的Git教程
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000
一个成功的Git分支开发模型
https://blog.csdn.net/qq_34651940/article/details/51891767
《一个成功的Git分支模型》为什么是有害的
https://www.jianshu.com/p/748e4892871a
2,Git的正确使用姿势
开发部目前使用Git的问题
1,提交内容混乱
2,出现很多的合并导致的无疑义提交,例如 “Merge branch ‘some-branch’ of git://git.some.domain/repository/”
3,三个主分支之间的频繁合并工作和产生的无疑义的合并信息
解决办法如下
必须的默认配置
git config --global pull.rebase preserve #拉取并变基
直接在master(或dev)分支上开发的场景模拟
1,master分支跟踪远端
2,一天的开发过程中常规性的commit多次
3,下班前对commit信息进行合并:git rebase -i origin/master #合并本地commit
4,pull #拉取并变基(有冲突就解决)
5,push (也可以先push,如果push不了,就pull后再push(有冲突就解决后push))
正宗的:在本地的工作分支上进行开发的场景模拟
1,master分支跟踪远端
2,签出本地工作分支f1
3,一天的开发过程中常规性的commit
4,下班前对commit信息进行合并:rebase -i master (编辑合并后的提交信息)
5,切换到master分支,merge
6,pull #拉取并变基(有冲突就解决)
7,push (也可以先push,如果push不了,就pull后再push(有冲突就解决后push))
强调:rebase只能用在本地分支
建议的Git工作模式规则
1,工作分支一定独立出来-->使得可以整理出有意义的Commit信息
2,使用rebase替代merge-->减少无意义的合并信息
3,使用master分支作为开发分支-->减少dev分支往master分支的合并工作
4,用release分支作为发布分支,发布前打tag-->减少分支的合并工作
5,每次测试都要产生新的release分支-->减少分支的合并工作
Alias
git rebase -i origin/master #合并本地commit
git config --global alias.tidy "rebase -i @{upstream}" #配置快捷方式
git config --global pull.rebase preserve #拉取并变基
3,Git基本命令
基本命令
先初始化再关联远程仓库
git init
git remote add origin https://github.com/xxxx.git
先克隆
git clone https://github.com/xxxx.git
本地添加和提交
git add README.md
git commit -m "first commit"
日志
git log --graph --pretty=oneline --abbrev-commit
远程仓库
git push -u origin master
git pull origin master --refusing to merge unrelated histories
分支
git branch
git checkout -b dev 从当前分支创建分支dev,并切换到dev分支
git checkout dev 切换到dev分支
关于Git分支和常用命令
我们clone代码到本地之后会保存成两个分支
本地分支和远程跟踪分支(origin/master)
我们所有的修改都会在本地分支中进行
Fetch操作会更新远程跟踪分支
Merge会将远程更新分支中的修改合并到本地分支
Pull = Fetch + Merge
Push会把本地分支推送到服务器,如果成功或做一次Fetch更新本地的远程跟踪分支使保持一致
关于差异比较
在Git的理念中本地分支和远程分支地位是一样的,所以在SVN中跟服务器的比较功能在Git中没有
执行git diff 的时候是工作空间和本地分支比较
Commit之后,工作空间和本地分支就没有区别了,git diff就没有结果
当远程分支Fetch后可以用git diff origin/master比较工作空间和远程分支的差异
标准代码提交流程
1,将修改的地方全部Commit到本地仓库,如果你还不想推送到远程仓库可以不用
2,Fetch远程代码到本地的跟踪分支
3,Merge本地仓库代码到工作空间,工作空间还有修改没有Commit时不能合并
4,Push本地仓库代码到远程服务器
冲突的解决
Merge后如果出现冲突,冲突的文件会被修改
方法一:
这个时候,重新编辑这个文件解决冲突,再Commit,再Push就会用本地的文件覆盖服务器的文件
方法二:
如果想撤销之前的Commit可以用一下命令
git log
git reset --hard commit_id
撤销后再Merge,再重新开发再Push
用远程代码强制覆盖本地代码
git fetch --all
git reset --hard origin/master
git rm file 会将文件从暂存区与磁盘上删除
推荐阅读
-
idea -- git使用的心得
-
【前端开发环境】前端使用GIT管理代码仓库需要掌握的几个必备技巧和知识点总结
-
IOS AFNetworking的Post失败及requestSerializer的正确使用
-
Java 关键字 volatile 的理解与正确使用
-
初来乍到,PHP setcookie怎么能正确使用?我写的代码只能设置两个中的一个,怎么办?
-
如何正确使用SSD提升电脑的速度和性能
-
Spring Boot中使用Actuator的/info端点输出Git版本信息
-
解析如何正确使用SqlConnection的实现方法
-
IOS AFNetworking的Post失败及requestSerializer的正确使用
-
Java 关键字 volatile 的理解与正确使用