Git
2020-08-14 14:56:09 0 举报AI智能生成
git详解
作者其他创作
大纲/内容
Git 工作流
Centralized 工作流
集中式工作流像 Subversion 一样，集中式工作流以中央仓库作为项目所有修改的单点实体
图例
功能工作流
这种工作流关注功能开发，不直接往master提交代码保证它是稳定并且干净的，而是从master拉取feature分支进行功能开发，团队成员根据分工拉取不同的功能分支来进行不同的功能开发，这样就可以完全隔离开每个人的工作。当功能开发完成后，会向master分支发起Pull Request，只有审核通过的代码才真正允许合入master
图例
Git Flow工作流
该种工作流会相对复杂一点，但非常适合用来管理大型项目的发布和维护。贯穿整个开发周期，master和develop分支是一直存在的。
图解
分支分配
master
master分支可以被视为稳定的分支，一般不允许直接往master分支提交代码，只允许往这个分支发起merge request，只允许release分支和hotfix分支进行合流
develop
develop分支是相对稳定的分支，用于日常开发，包括代码优化、功能性开发。
feature
feature分支从develop分支拉取，特性开发会在其上进行，开发完毕合后并到develop分支。
release
release分支从develop分支拉取，用于回归测试，完成后打tag并合入master和develop。
hotfix
hotfix分支用于紧急修复上线版本的问题，修复后打tag并合入master和develop。
新功能的开发
所有版本新功能的开发都在feature上开发，这样确保了dev分支在开发的时候保留关键节点
在开发过程中在自己的分支开发可以随意操作分支，不会对其他人的代码产生破坏
版本的发布与回退
master上是干净的，所有的提交都是一个版本记录,当需要版本回退时，只需要检出某个历史版本，即可快速回退
过时分支的处理
除了 master 与 develop 是永久性分支以外，其他分支在使用完以后都需要及时清理，保持分支的简洁
合并分支
压缩提交
当Feature分支往Develop分支上合并或者Develop分支往Master分支上合并时，需要对Feature分支上的提交进行压缩，保留几个有效的提交，提交无用提交
常用的压缩命令是 git rebase
Hotfix修复
Hotfix分支主要用于修复master上的分支，并合并一份到Develop上，保证Develop后续分支不会出错
但是如果Realase分支已经存在了，那么就无法获取到Develop上的更改，这时候Hotfix也需要往Release分支上合并一次
记住不是Develop往Release上合并，这样如果处理不当，会无意导致Develop上在Release之后的更改合并到Release上，导致问题出现
新项目
当我们有多个项目，他们的功能稍微不同，但是却基于同一个项目，该如何处理？
如果两个项目以后要合并为一个项目，那么推荐在原有主分支上重新拉一个保护分支，用作新项目的主分支
否则重新创建一个仓库，将代码迁移一份到新项目中继续开发
Git Flow 真的完美吗？
合并问题
所有人在自己的代码开发会导致代码异化增加，冗长的代码提交会增加合并冲突的几率以及冲突代码量增加
不可在 feature 过长时间进行开发，否则feature上的代码很可能过时，develop上的代码更新不会反馈到feature分支上
临时性分支的代码最终走向还是 develop ，feature 只是在某个程度上缓解了 develop被污染的可能
减少代码异化
feature分支在开发时，应每隔一段时间往dev上合并一次代码，同时从dev上合并一次代码到feature上
如果项目需要调整目录结构、大幅改动时，应通知所有feature上开发的人员合并代码到dev上，再重新拉取新feature，否则容易导致代码大量冲突
持续集成
Git Flow 反馈时间长，集成周期相对较长，不符合持续集成的思想
相较与其他工作流模型，Git Flow 的持续集成能力较弱
繁杂的分支
在开发过程中，会生产很多分支，如果命名不当，将导致分支混乱，没有丰富的git使用经验的人员很可能搞错，所以在使用时在命名和分支层次上需要特别注意
多个团队同时开发一个项目，容易导致分支失控
惨遭吐槽
Gitflow不是Git社区的官方推荐工作流，也不是Github所推荐的工作流，Gitflow在企业软件开发中甚至不是一个最佳实践
那为什么还有那么多人使用它？
因为没有比它更适合企业开发的工作流模型了
Forking 工作流
Forking工作流常用于开源项目，它有一个公开的中央仓库，其他贡献者可以Fork（克隆）这个仓库作为你自己的私有仓库，开源项目维护者可以直接往中央仓库push代码，而代码贡献者只能将代码push到自己的私有仓库，只有项目维护者接受代码贡献者往中央仓库发起的pull request才会真正合入。
图解
Trunk based Development
Trunk based Development，又叫 主干开发 ，是一套代码分支管理策略，开发人员之间通过约定向被指定为 主干 的分支提交代码，以此抵抗因为长期存在的多分支导致的开发压力。此举可 避免分支合并的困扰，保证随时拥有可发布的版本 。
Trunk Based Development
Git Hub flow
GitHub Flow 是一个更轻量级的软件开发模型，示意图如下。它摒弃了 Git Flow 中繁杂的分支， 只保留一个主分支 master 。开发新功能时从 master 分支上拉取 feature 分支，开发完成后发起 Pull-Request ，小组内进行评审和反馈，此时也进行 Code Review
图解
最佳实践
提交代码之前都记得先pull一下，确保本地仓库与远程仓库同步，避免合并conflict，产生新的提交节点
git push -f 只允许在自己的分支操作，否则很可能将别人的代码搞丢
及时清理过时分支
使用rebase压缩提交
克隆请帮忙点个赞，谢谢 ☺
历史记录
2020-8-12 创建导图
参考资料
官网
https://www.git-scm.com/doc
https://www.cnblogs.com/jeffery-zou/p/10280167.html
https://insights.thoughtworks.cn/gitflow-consider-harmful/
https://www.git-tower.com/learn/git/ebook/cn/command-line/appendix/why-git
git rebase
https://zhuanlan.zhihu.com/p/139321091
Git概念
Git 是什么
Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目
Git 能做什么
文件版本管理
作为版本管理系统诞生的Git，最重要的是可以帮助团队进行文件管理，各种源代码和文档等。
代码评审
代码评审作为软件开发流程中重要的一环，是项目顺利进行提供有效的保障，使用过Github的人对Pull Request应该不会陌生，如果高效进行代码就是另一个问题了
持续集成
持续集成作为软件的开发和发布流程中最重要的一环，通过进行单元测试、自动化测试和自动构建发布，可以非常容易发现和改正Bug, 通过钩子(Hook)，Git可以和构建工具（如Jenkins）结合构建持续集成环境。
为什么使用Git
节省时间
Git 运行快速。尽管我们在这里讨论的只是运行一个命令所需要的几秒钟，但是把它累积在你的日常工作中就是一个不小的飞跃了
离线工作
对于一个像 Subversion 或者 CVS 的集中式版本控制系统来说，如果你没有连接到中央仓库，你就不能很好的工作。如果使用 Git ，几乎所有的东西都可以简单地在你的本地机器上完成。当你联网后，就可以轻松将本地仓库与远程仓库同步
操作回退
当你忘了备份资料，然后在后续几天对这份资料一阵操作，结果却发现很多内容都有问题，这时候想回退到之前的内容，那已经为时已晚了。而使用 Git 的最大好处就在于，几乎在所有的情况下你都能 “撤消” 你的错误操作，但你的代码提交后，你能退回到任何一个你想要的节点上
可靠性高
Git 安装
https://www.git-scm.com/downloads
傻瓜式安装-略
Git 常用工具
各种IDE
SourceTree
Git Bash/Git GUI
各种 Terminals
常用Git远程仓库
Github
Gitlab
Gitee
阿里云Code
搭建私有仓库
Git常用命令
git init
创建仓库
git clone
克隆（拉取）仓库
git pull
拉取最新代码
git add
加入到暂存区
git status
工作目录修改状态
git commit
提交
git push
推送到远程分支
git stash
加入到储藏区
git stash pop|drop|list
从储藏区获取代码
git checkout
检出
git branch
分支操作
git merge
合并
git rebase
变基
git tag
tag操作
...
Git 体系结构
ssh 与 https
https 是基于 username/password 认证，每次拉取代码都需要登录，当然，也可以配置记住账号密码免登录
ssh 是基于秘钥对来进行免等处理，通过ssh--keygen 生成秘钥对，将私钥配置到git远程仓库，即可实现免登
README.md
.gitignore
Work Directory(工作目录)
Stage(暂存区）
Stash(储藏区)
Local Repository （本地仓库）
Remote Repository (远程仓库）
git command recipes
0 条评论
下一页
