引入GIT.pptx

引入GIT TopCode 我们现阶段在版本控制上的问题 使用SVN进行版本控制 基本只用到代码提交、更新、冲突解决 无法离线进行版本控制 单打独斗还凑合，打群架就毫无章法 没有系统学习过SVN的理论，碰到问题就百度，知识是零散的、模糊的 进入GIT时代 Git是一款免费、开源的分布式版本控制系统，是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。 Linus是Linux的作者。 Git是分布式的版本控制工具 Git用户之间是平等的，即使没有中心服务器也能够正常工作 01 GIT是目前最流行的版本控制工具 在网络上开源的项目几乎都使用git进行代码管理，并且git的平台比较多，例如开源中国、Github、BitBucket和Gitlab等，使用主流工具可以降低我们的使用成本。 02 我们已经收集了系统学习的材料和踏出第一步 Git也是一个协作工具，包括个人使用、团队使用流程，都应该有系统的学习资料和方法，而我们已经收集相关材料，并步入学习实践阶段 04 我们放弃SVN的代价低 我们并没有在SVN上投入精力，项目中即使使用了SVN但我们往往只认最新的源代码而不在乎它的历史记录 03 那么我们如何开始？ 我们如何开始？ 执行起来还缺点什么？ 我相信，我们从SVN切换到GIT的阻力不大，但让每个人都系统的学习GIT，顺利的使用GIT以及后续GIT知识扩展、分享这需要打造一个良好的学习氛围和有一个先行者。 初始项目 建立一个空的Git本地仓库 git config/init 添加/修改/删除文件提交 从工作空间添加到暂存区，从暂存区提交到本地仓库 git add/commit/rm/status 分支切换、打Tag和版本回退 多分支开发和合并、打Tag和查看历史版本 branch/stash/tag/merge/diff/log/reflog/checkout Git远程仓库 从远程仓库克隆以及提交代码到远程仓库 生成公钥私钥 git remote/clone/push/pull 工作流程 Git Flow、Github Flow和Gitlab Flow 直接开干吧 工作流程 Git 作为一个源码管理系统，不可避免涉及到多人协作。 协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。工作流程在英语里，叫做workflow或者flow，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。 Git Flow Github Flow Gitlab Flow 共性 - 功能驱动式开发（FDD）： 需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。 完成开发后，该分支就合并到主分支，然后被删除。 Git Flow 拥有2个长期分支:develop/master 存在3种短期分支: 功能分支(feature branch) 补丁分支(hotfix branch) 预发分支(release branch) 一旦开发完成，短期分支将合并到develop或master分支，并且被删除 优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支，多数工具以master为默认分支，但开发在develop，导致需要经常切换分支，非常烦人。 更大问题在于，这个模式是基于版本发布的，目标是一段时间以后产出一个新版本。但是，很多网站项目是持续发布，代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。 Github Flow Github flow 是Git flow的简化版，专门配合持续发布。它是 G 使用的工作流程。 第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。 第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。 第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。 第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可） Github flow 的最大优点就是简单，对于持续发布的产品，可以说是最合适的流程。 问题在于它的假设：master分支的更新与产品的发布是一致的。也就是说，master分支的最新代码，默认就是当前的线上代码。 可是，有些时候并非如此，代码合并进入master分支，并不代表它就能立刻发布。比如，苹