Git的使用（1）-CSDN博客

本文链接：https://blog.csdn.net/zl_StepByStep/article/details/77604274

Git安装配置：http://www.runoob.com/git/git-install-setup.html

一、Git简介

什么是Git？

Git是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开源的版本控制软件。Torvalds开始着手开发Git来替代BitKeeper，后者之前一直是Linux内核开发人员在全球使用的主要源代码工具。尽管最初Git的开发是为了辅助Linux内核开发的过程，但是我们已经发现在很多自由软件项目中也使用了Git。

Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。

Git与SVN的区别：

Git不仅仅是个版本控制系统，它也是个内容管理系统(CMS),工作管理系统等。如果你是一个具有使用SVN（Subversion）背景的人，你需要做一定的思想转换，来适应Git提供的一些概念和特征，它俩有以下区别：

1、Git是分布式的，SVN不是：这是Git和其它非分布式的版本控制系统（如SVN、CVS）最核心的区别。

2、Git分支和SVN分支不同：分支在SVN中只是版本库的另外的一个目录。

3、Git把内容按元数据（Metadata，数据的数据）方式存储，SVN是按文件存储。

4、Git没有一个全局的版本号，而SVN有：目前为止，这是Git跟SVN相比，Git缺少的最大的一个特征。

5、Git的内容完整性要优于SVN：GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。

二、Git中的一些基本概念

①工作区：就是在电脑里能看到的目录

②版本库：工作区有一个隐藏目录 .git，这个不算工作区，而是Git的版本库，版本库里存了很多东西，其中最重要的就是暂存区（stage或index），Git为我们自动创建的第一个分支master，以及指向master分支的一个指针叫做HEAD

③远程库（中央仓库）：

结构如下图：

图中左侧为工作区，右侧为版本库。在版本库中标记为 "stage" 的区域是暂存区（stage, index），标记为 "master" 的是 master 分支所代表的目录树。图中我们可以看出此时 "HEAD" 实际是指向 master 分支的一个"游标"。

当对工作区修改（或新增）的文件执行 "git add" 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。

当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。

当执行 "git reset HEAD" 命令时，暂存区的目录树会被重写，被 master 分支指向的目录树所替换，但是工作区不受影响。

当执行 "git rm --cached <file>" 命令时，会直接从暂存区删除文件，工作区则不做出改变。

当执行 "git checkout ." 或者 "git checkout -- <file>" 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区的改动。

当执行 "git checkout HEAD ." 或者 "git checkout HEAD <file>" 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。

工作区内修改的代码提交到远程库需要三步：

◆git add 把代码文件添加到暂存区

◆git commit 把暂存区的内容提交到当前分支

◆git push 把代码推到远程库

三、Git工作流

掌握工作流能更好地实现团队间通过远程库进行协作。

☞中心化的工作流

中心化的工作流需要远程库存在一个master分支即可

A和B同时对项目进行修改，A和B的本地都有了各自的历史，A先提交代码到远程库，不会发生问题，B再提交的时候就会产生冲突。

远程库在这里作为中央仓库代表官方项目，因此，它的提交历史应该是不可更改的，若是开发者的本地提交和中央仓库分叉Git会拒绝将他们修改推送上去，因为这会覆盖官方提交。

冲突解决办法：先将代码拉到本地，再执行rebase操作，完整命令：

合并过程如有冲突，需手动进行修改，可以用git status查看当前工作区状态，合并完成后：

☞Feature分支的工作流

团队成员在不同的分支上修改不同功能，等待功能模块完成后再合并到主分支。隔离功能开发后，通过pull request合并代码，也可以和其他成员沟通，其他成员对代码查看和提问。

☞GitFlow工作流

GitFlow工作流围绕项目发布定义了一个严格的分支模型，方便管理大型项目。和功能分支相比，这种工作流没有增加任何新的概念或命令。除了功能分支之外，它还为准备发布、维护发布、记录发布分别是用了单独的分支。

它有两个分支来记录项目历史。master分支存储官方发布历史，develop分支整合功能分支，这两个分支不直接交互。
开发分支：如果develop分支的新功能足够发布，可以从develop分支fork一个发布分支，只有和发布相关的任务应该在这个分支进行，如修复bug、生成文档等。完成发布后，发布分支合并会master和develop分支。

维护分支，通常有以下约定： * 从develop创建 * 合并进master分支 * 命名规范release-*

☞Fork工作流

Fork工作流与其他工作流不同的是，每个开发者都有一个远程代码库和本地代码库，Fork工作流的主要优点在于贡献可以轻易地整合进项目，而不需要每个人都推送到单一的远程库，开发者将代码推到个人仓库后在告知中央仓库需要合并代码。
项目管理员执行合并操作时可以有两步： ① 直接检查PullRequest中检查代码 ②将代码拉取到本地仓库然后手动合并