Git版本控制

1.版本控制概念

如果在开发团队中没有使用版本控制，多个开发人员共同负责同一个软件或文档的开发，每个人在各自
的机器上有整个软件文档的备份，并对之实施编程开发，在分别完成各自任务之后，再通过文本比对工
具将各自机器上的不同版本的程序整合到一台机器上。没有进行版本控制或者版本控制本身缺乏正确的
流程管理，在软件开发过程中将会引入很多问题，如软件代码的一致性、软件内容的冗余、软件过程的
事务性、软件开发过程中的并发性、软件源代码的安全性，以及软件的整合等问题。

版本控制的目的是实现开发团队并行开发、提高开发效率的基础。其目的在于对软件开发进程中文件或
目录的发展过程提供有效的追踪手段，保证在需要时可回到旧的版本，避免文件的丢失、修改的丢失和
相互覆盖，通过对版本库的访问控制避免未经授权的访问和修改，达到有效保护企业软件资产和知识产
权的目的。

版本控制的功能在于跟踪记录整个软件的开发过程，包括软件本身和相关文档，以便对不同阶段的软件
及相关文档进行表示并进行差别分析，对软件代码进行可撤消的修改，便于汇总不同开发人员所做的修
改，辅助协调和管理软件开发团队。

2.版本控制工具

Visual Source Safe(简称VSS）

VSS是美国微软公司的产品，目前常用的版本为6.0版。VSS是配置管理的一种很好的入门级的工具。

易学易用是VSS的强项，VSS采用标准的windows操作界面，只要对微软的产品熟悉，就能很快上手。
VSS的安装和配置非常简单，对于该产品，不需要外部的培训（可以为公司省去一笔不菲的费用）。只
要参考微软完备的随机文档，就可以很快的用到实际的工程当中。

VSS的配置管理的功能比较基本，提供文件的版本跟踪功能，对于build和基线的管理，VSS的打标签的
功能可以提供支持。VSS提供share（共 享)、branch(分支）和合并（merge)的功能，对于团队的开发
进行支持。VSS不提供对流程的管理功能，如对变更的流程进行控制。

VSS不能提供对异地团队开发的支持。此外VSS只能在windows平台上运行，不能运行在其他操作系统
上。 有软件提供商提供VSS插件，可以同时解决VSS跨平台和远程连接两个问题，例如SourceAnywhere for VSS, SourceOffSite等。

VSS的安全性不高，对于VSS的用户，可以在文件夹上设置不可读，可读，可读/写,可完全控制四级权
限。但由于VSS的文件夹是要完全共享给用户后，用户才能进入，所以用户对VSS的文件夹都可以删
除。这一点也是VSS的一个比较大的缺点。

VSS没有采用对许可证进行收费的方式，只要安装了VSS，对用户的数目是没有限制的。因此使用VSS的
费用是较低的。

微软不再对VSS提供技术支持。

Concurrent Version System(简称CVS）

CVS是开发源代码的配置管理工具，其源代码和安装文件都可以免费下载。

CVS是源于unix的版本控制工具，对于CVS的安装和使用最好对unix的系统有所了解能更容易学习，
CVS的服务器管理需要进行各种命令行操作。目前，CVS的客户端有winCVS的图形化界面，服务器端也
有CVSNT的版本，易用性正在提高。

CVS的功能除具备VSS的功能外，还具有：

它的客户机/服务器存取方法使得开发者可以从任何因特网的接入点存取最新的代码；它的无限制的版
本管理检出(checkout)的模式避免了通常的 因为排它检出模式而引起的人工冲突；它的客户端工具可以
在绝大多数的平台上使用。同样，CVS不提供对变更流程的自动管理功能。

一般来说，CVS的权限设置单一，通常只能通过CVSROOT/passwd, CVSROOT/readers,
CVSROOT/writers文 件，同时还要设置CVS REPOS的物理目录权限来完成权限设置，无法完成复杂的
权限控制；但是CVS通过CVS ROOT目录下的脚本，提供了相应功 能扩充的接口，不但可以完成精细的
权限控制，还能完成更加个性化的功能。

CVS是开发源码软件，无需支付购买费用。
同样因为CVS是开发源码软件，没有生产厂家为其提供技术的支持。如发现问题，通常只能靠自己查找
网上的资料进行解决。

SVN

SVN全名Subversion，即版本控制系统。

SVN与CVS一样，是一个跨平台的软件，支持大多数常见的操作系统。作为一个开源的版本控制系
统,Subversion 管理着随时间改变的数据。 这些数据放置在一个中央资料档案库中。 这个档案库很像一
个普通的文件服务器, 不过它会记住每一次文件的变动。 这样你就可以把档案恢复到旧的版本, 或是浏
览文件的变动历史。Subversion 是一个通用的系统, 可用来管理任何类型的文件, 其中包括了程序源码。

SubVersion：实现服务系统的软件。

TortoiseSVN：是SVN客户端程序，为windows外壳程序集成到windows资源管理器和文件管理系统的
Subversion客户端。

SVNService.exe：是专为 SubVersion 开发的一个用来作为 Win32 服务挂接的入口程序。

AnkhSVN：是一个专为Visual Studio提供SVN的插件。

Git

Git是一个开源的分布式版本控制系统，用以有效、高速的处理从很小到非常大的项目版本管理。

Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，后者之前一直是 Linux 内核开
发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得 BitKeeper 的许可证并不适合开
放源码社区的工作，因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统。尽管最初 Git 的开发
是为了辅助 Linux 内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如
最近就迁移到 Git 上来了，很多 Freedesktop 的项目也迁移到了 Git 上。

Git的使用

Git 与 SVN 区别

1、Git 是分布式的，SVN 不是：这是 Git 和其它非分布式的版本控制系统，例如 SVN，CVS 等，最核心的区别。
2、Git 把内容按元数据方式存储，而 SVN 是按文件：
所有的资源控制系统都是把文件的元信息隐藏在一个类似 .svn、.git 等的文件夹里。
3、Git 分支和 SVN 的分支不同：
分支在 SVN 中一点都不特别，其实它就是版本库中的另外一个目录。Git 分支是指针指向某次提交，而 SVN 分支是拷贝的目录。这个特性使 Git 的分支切换非常迅速，且创建成本非常低。Git 有本地分支，SVN 无本地分支。在实际开发过程中，经常会遇到有些代码没写完，但是需紧急处理其他问题，若我们使用 Git，便可以创建本地分支存储没写完的代码，待问题处理完后，再回到本地分支继续完成代码。
4、Git 没有一个全局的版本号，而 SVN 有：目前为止这是跟 SVN 相比 Git 缺少的最大的一个特征。
5、Git 的内容完整性要优于SVN：
Git 的内容存储使用的是 SHA-1 哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网
络问题时降低对版本库的破坏。

Git的安装

下载地址:https://www.git-scm.com/download/win


检验是否安装成功,桌面上鼠标右击后:

Git的实现原理（关注）

(1)工作区： 该区域中是对项目的某个版本独立提取出来的内容。这些从Git仓库的压缩数据库中提取出来的文件，放在磁盘上供你使用或修改

(2)暂存区： 暂存区域是一个文件，保存了下次将提交的文件列表信息，一般在Git仓库目录中。 有时也称作“索引”。

(3)git仓库区： 该区域用来保存项目的元数据和对象数据库。 这里是GIt中最重要的部分，从其它计算机克隆仓库时，拷贝的就是这里的数据。本地和远端都会有一个仓库一一对应

工作区workspace（可以认为是本地的代码）-> 暂存区index （可以认为是一个缓冲区）

git add 文件名

暂存区index->本地仓库Repository

git status 先查看文件状态
git commit -m “提交描述”

提交描述是必要的

本地仓库Repository -> 远程仓库Remote

git push 服务器地址 分支名

初始化仓库

(1)新建文件夹，进入到该目录,右键打开git bash
(2)在文件夹内初始化git(创建git仓库)

命令:git init (会生成一个.git的隐藏文件)

(3)仓库中添加信息（可以用git status命令查看暂存区文件的状态）

git add 文件名-> 结果:new file：文件名 //工作区到暂存区
git add * 添加所有文件
git commit -m ‘描述信息’ //暂存区到仓库

举例：

(4)仓库中修改信息
修改完成后按照原来的程序再执行

(5)删除文件

git rm 文件名 如果想要删除文件夹，则添加参数 -r
git commit -m ‘提交描述’

(6)删除文件夹
当我们需要删除暂存区或分支上的文件, 但本地又需要使用, 只是不希望这个文件被版本控制(即不希望该文件和版本库有联系), 可以使用

git rm -r --cached 文件夹名称
实例: git rm -r --cached target 删除target文件夹
git commit -m '删除了target' 提交,添加操作说明

注意：添加和删除操作都需要commit提交否则只是影响了暂存区而非版本库

Git远程服务器介绍

GitHub介绍

通过git管理github托管项目代码
gitHub是一个面向开源及私有软件项目的托管平台，因为只支持git 作为唯一的版本库格式进行托管，
故名gitHub。
gitHub于2008年4月10日正式上线，除了git代码仓库托管及基本的 Web管理界面以外，还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱(报表)、代码片段分享(Gist)等功能。目前，其注册用户已经超过350万，托管版本数量也是非常之多，其中不乏知名开源项目 Ruby，on Rails、jQuery、 python等。

访问地址:https://github.com/

GitLab

GitHub 和 GitLab 都是基于 web 的 Git 仓库，使用起来二者差不多，它们都提供了分享开源项目的平台，为开发团队提供了存储、分享、发布和合作开发项目的中心化云存储的场所。
GitHub 作为开源代码库，拥有超过 900 万的开发者用户，目前仍然是最火的开源项目托管平台，
GitHub 同时提供公共仓库和私有仓库，但如果使用私有仓库，是需要付费的。
GitLab 解决了这个问题，你可以在上面创建私人的免费仓库。
GitLab 让开发团队对他们的代码仓库拥有更多的控制，相比较 GitHub , 它有不少特色：
(1) 允许免费设置仓库权限；
(2) 允许用户选择分享一个 project 的部分代码；
(3) 允许用户设置 project 的获取权限，进一步提升安全性；
(4) 可以设置获取到团队整体的改进进度；
(5) 通过 innersourcing 让不在权限范围内的人访问不到该资源；
所以，从代码的私有性上来看，GitLab 是一个更好的选择。但是对于开源项目而言，GitHub 依然是代
码托管的首选。

访问地址:https://git.lug.ustc.edu.cn/users/sign_in

gitee(码云)

码云（Gitee）是 OSCHINA 推出的代码托管协作开发平台，支持 Git 和 SVN,提供免费的私有仓库托管。2016 年推出企业版，提供企业级代码托管服务，成为开发领域领先的 SaaS 服务提供商。使用 GitHub 时，国内的用户经常遇到的问题是访问速度太慢，有时候还会出现无法连接的情况。如果你希望体验 Git 飞一般的速度，可以使用国内的代码托管与开发协作平台 —— Gitee。除了访问速度更快以外，Gitee 还提供了免费的私有仓库供个人开发者使用。同时，Gitee 也有着国内数一数二的开源生态，这里有非常多的优秀开源项目和开发者，你可以在这里和他们无障碍地沟通交流，不管是找开源项目还是分享自己的开源项目，Gitee 都是极佳的选择。
作为国内代码托管平台的佼佼者，目前已经有超过 500 万名开发者在 Gitee 上托管了 1000 余万个代码仓库，而其提供了研发管理、代码托管、文档管理服务的企业版的服务客户也超过了 10 万家。

访问地址:https://gitee.com/

基本概念(Gitee)

(1) 仓库（Repository）
仓库即你的项目，你想在github上开源一个项目，那就必须要新建一个repository,如果你开源的项目多，那你拥有的仓库也就很多

(2) 收藏(star)
仓库主页的star按钮，意思是收藏项目的人数。

(3) 复制克隆项目(fork)
在原项目的基础上新增代码和结构，也可以理解成拿别人的代码进行二次加工。Fork后，会在自己账号下，生成自己的相同仓库

(4) 发起请求(pull request，简称PR)
这个是基于fork的，当其他人改进完代码后，想将这个项目合并到原项目，则这个时候会给你发起一个pull request。如果接受了请求，这个时候就可以拥有改进的项目了

(5) 关注(watch)
即观察，可以随时看到被关注项目的更新

(6) 事务卡片（Issue）
发现代码有bug,但是目前还没成型，需要讨论时使用当别人发现你的问题时，会提个lssue

(7) Gitee主页
账号创建完后，点击导航栏gitee图标即可进入主页。左侧显示功能列表，右侧显示仓库动态

(8) 仓库主页
仓库主页主要显示项目的信息，如:代码，版本，收藏，关注，fork等

创建仓库(Gitee)

一个git库对应一个开源项目

仓库主页说明

在这里ssm0923就是你的仓库名称

仓库管理(Gitee)

新建文件

编辑/删除文件

被删除的文件如何查看信息:

上传文件(可以同时选择多文件)：

下载项目:

Gitee issue(问题)
张三发现李四的开源git,提交issue,李四登录gitee后，和张三交流并关闭issue

基本概念实战

收藏，关注，复制克隆项目,发起请求，事务卡片
删除仓库:

初始化git的基本信息

设置登录的账户信息: 用户名和邮箱地址是本地git客户端的一个变量，每次commit都会用用户名和邮箱纪录。

设置用户名: git config --global user.name ‘用户名’
设置用户名邮箱: git config --global user.email ‘邮箱’

实例: git config --global user.email ‘123@qq.com’
命令执行位置:桌面右击->git base here

注意:该设置在gitee仓库主页显示谁提交的文件,如果想要修改用户信息，则将该命令再执行一次

查看设置: git config --list

git管理远程仓库

目的:备份，实现代码共享
实现过程:
客户端:
(1)将本地项目提交到git
(2)建立本地和远程仓库的关系
步骤1:
git克隆操作：将远程仓库的项目复制到本地

命令: git clone 仓库地址

仓库地址:
gitee:

github:

注意:初始化操作进行一次即可,要先初始化

步骤2:
git push 将本地仓库提交到远程 （注意先提交到缓存区，再提交到仓库，最后提交远程）

其中最后git push的时候会让你输入账号和密码，就是初始化时候的用户名和邮箱

步骤3：要更新你的本地仓库至最新改动，执行：
git pull 从非默认位置更新到指定的url。
比如：

git pull http://git.example.com/project.git

实例:
cd 进入仓库

IDEA+Git

IDEA关联Git
IDEA自身路径需要在英文目录

IDEA配置Git客户端:

File — Settings — Version Control — Git关联Git安装目录下的
bin/git.exe执行文件(这个就是git的客户端指令，类似svn.exe)

下载gitee插件

添加信息（登录Gitee）

注意:登录时，使用邮箱登录

本地项目上传到服务器（注意先初始化git，步骤在前面。按照Gitee上的步骤进行绑定也行。）

项目上传时以下两个文件可以不上传：

当关联完Git后创建新文件时，会提示是否同步文件到Git：

项目的快捷上传与更新

当该项目已经上传到版本库后，右上角会出现两个图标：

箭头是更新项目，就是从服务器下载文件到本地
对钩是提交项目，是将本地文件上传到服务器

如果点击提交项目：
首先勾选要上传的文件，然后写描述信息（必须写）

然后点击Commit提交，选择提交并上传（Commit and Push）：

再点击Push即可：

如果点击更新项目：

选择OK后项目就会更新

服务器项目下载到本地

Linux下的Git（Ubuntu系统）

安装git

通过一下命令安装git：

sudo apt-get update
sudo apt-get install git

验证安装：

git --version

显示git版本信息即安装成功

配置git

git 通过git config工具来设置git的外观和行为，有三处文件可以配置git config：

1. /etc/gitconfig文件：该文件包含系统上每个用户及他们仓库的通用配置。可以传递 –system选项 让git读写此文件中的配置
2. 用户home目录下的~/.gitconfig或~/.config/git/config文件，只针对当前用户。可以传递 –global选项 让git读写此文件中的配置
3. 当前使用的git目录中的config文件（即.git/config）：只针对该仓库

上述配置的优先级递增（作用范围越小，优先级越高），所以.git/config中的配置会覆盖~/.gitconfig中的配置，以此类推。
通常只需修改~/.gitconfig文件中的配置即可（即针对当前系统用户）

设置git的用户信息

安装完 Git 应该做的第一件事就是设置你的用户名称与邮件地址，因为每一个 Git 的提交都会使用这些信息，并且它会写入到你的每一次提交中。 这样做很重要，不可更改：

git config --global user.name 用户名
git config --global user.email 邮箱地址

再次强调，如果使用了 –global选项，那么该命令只需要运行一次，因为之后无论你在该系统上做任何事情， Git 都会使用那些信息。
当你想针对特定项目使用不同的用户名称与邮件地址时，可以在那个项目目录下运行没有 --global选项的命令来配置。
如在某项目目录下运行以下命令，就会为该项目单独配置用户名和邮箱：

git config user.name 用户名
git config user.email 邮箱地址

检查配置信息

使用 git config --list 命令来列出所有 Git 当时能找到的配置

从远端仓库获取代码（git clone）

该命令会将指定仓库地址的代码克隆到本地仓库（Repository）
全克隆命令（克隆master分支）：

git clone https://github.com/XXX/XXX.git

以上命令执行后会在当前目录 （即终端所在目录）生成一个XXX目录（即本地目录名和远端仓库名一致） ，在该目录中存放代码。

克隆到指定目录命令：

git clone https://github.com/XXX/XXX.git 指定目录名

以上命令执行后会在当前目录 （即终端所在目录）生成一个指定目录名的目录 ，在该目录中存放代码。

克隆指定分支
方案一：

git clone --branch 分支名称 仓库_url

方案二：

git clone -b tags 仓库_url （需要分支的tag）

这两个方案是一样的，这里 -b 只是 --branch 的别名。
方案三：

git clone --single--branch 分支名称   仓库_url      （获取指定分支的代码）

此方案可以提高下载速度，因为它不会看到其它分支。

检查当前文件或文件夹状态（git status）

git status命令用于查看文件或文件夹在工作区，暂存区的状态。包含三种状态：

Changes to be committed:
(use “git restore --staged …” to unstage)
new file: bbbb.txt

Changes not staged for commit:
(use “git add …” to update what will be committed)
(use “git restore …” to discard changes in working directory)
modified: bbbb.txt

Untracked files:
(use “git add …” to include in what will be committed)
.idea/
designpatterns/
“javaDoc/~$it\345\270\270\347\224\250\345\221\275\344\273\244.docx”

Changes to be committed: 表示已经从工作区add到暂存区的file（文件或文件夹），可以通过 git restore --staged filename 命令将该file从暂存区移出，此时只有工作区有该file（文件或文件夹），该file的状态就变为Untracked files。

Changes not staged for commit: 表示工作区，暂时区都存在的file（文件或文件夹），并且该file在工作区进行了修改或删除，但是没有add到暂存区。
可以通过 git add file命令将变更（修改，删除）的file add到暂存区，此时该file失去Changes not staged for commit状态，也就是Changes not staged for commit将没有该file的记录了。
可以通过 git restore file命令取消该file在工作区的变更，那么暂存区的file内容还是以前的，并且file在Changes not staged for commit状态下没有记录。

Untracked files: 表示只在工作区有的file（文件或文件夹），也就是在暂存区没有该file。

例子：对工作区（workspace）中的README.md文件进行修改并提交改动到本地仓库（Repository）

首先通过任何你喜欢的编辑器对项目中的 README.md 文件做一些改动并保存。
然后通过 git status 命令查看README.md 文件的当前状态：发现是Changes not staged for commit: （改动文件未提交到暂存区）

然后通过git add命令将README.md文件添加到暂存区：

git add README.md

PS：如果想添加所有文件到暂存区，只需用以下命令：

git add .

添加完后再次通过 git status 命令查看README.md 文件的当前状态：发现变成了Changes to be committed: （文件已提交到暂存区）

最后通过git commit命令将README.md 文件的改动提交到本地仓库（Repository）即可 （无需指定具体文件，自动识别）：
通过 -m 参数可直接在命令行里输入提交的描述文本

git commit -m '描述文本'

使用 commit 模板

通过commit 模板我们可以更加便捷的设置代码提交的格式。
可根据已经规定的 commit msg 格式编写 commit 模板文件
然后针对当前用户下所有项目仓库，或某个仓库进行模板设置

#针对某个仓库的配置，在指定仓库的目录中执行
git config --local commit.template 模板文件绝对路径
#针对当前用户下所有项目仓库的配置
git config --global commit.template 模板文件绝对路径

指定了commit 模板后，还需要设置模板对应的编辑器，因为每次提交前都要编辑模板：

#core.editor后面跟的是要设置的编辑器 ，我这里设置的为vim
git config --global（或--loacel） core.editor vim

然后每次进行提交的时候只要
git commit 然后回车就会弹出我们设置的模板，编辑完成后保存退出就进行自动提交了。
例子：
1.编写模板文件
创建cong_complate 文件，文件内容如下：

问题：
原因：
解决方案：
作者：
日期：

文件名称和文件内容可以根据自己的需求进行修改

2.设置模板

# commit.template 后面是自己创建的模板文件的绝对路径
git config --global commit.template  /home/song/work/song_complate

3.设置编辑器

#core.editor后面跟的是要设置的编辑器 ，我这里设置的为vim
git config --global core.editor vim

4.输入git commit命令 然后回车

转载自文章

代码推送前更新操作（git pull --rebase）（关注）

主要为了防止本地代码非最新状态导致代码无法推送问题
通过以下命令实现：

git pull 远程仓库地址 分支名称 --rebase

本地分支处在非最新状态的原因分析

转载自文章

首先明确一个概念：git pull命令其实就是git fetch命令和git merge命令的整合版
git fetch命令用于将远程仓库的改动同步到本地，也就是将本地的origin/master指针指向远程仓库最的新节点
git merge命令用于将origin/master指针指向的远程仓库的内容合并到本地master分支上

而git pull这一个命令就完成了上面两步，虽然便捷了但是不推荐使用，分开处理最好。因为git pull会直接合并，而不会等你确认，如果一旦合并错了，还是比较麻烦的。

---

本地分支处在非最新状态的原因分析:
Git 的 clone 命令会为你自动将远程主机命名为origin，拉取它的所有数据，创建一个指向它的 master 分支的指针，并且在 本地将其命名为 origin/master。
同时Git 也会给你一个与 origin 的master 分支在指向同一个地方的本地 master 分支，这样你就有工作的基础。

也就是说本地存在一个origin/master指针用于和远端的master分支同步，但这种同步是需要手动的（使用git fetch命令）。
然后本地也有一个master分支，开发者可以在该分支上进行开发操作，但只会影响本地仓库而不会影响远程仓库，需要通过git push命令将本地仓库的修改提交到远程仓库才行。

但是当本地仓库和远程仓库之间出现差异时，是无法git push成功的。
这就需要先将远程仓库的差异同步到本地仓库（也就是将origin/master指针指向远程仓库的最新节点），然后调用git merge命令合并本地仓库与远程仓库的差异。然后才能正常push。

例子：本地有提交，远程也有别人的推送（原同步位置在B2）
远程库（origin）有人推送，提交了C0和C1：

本地提交了D0和D1：
此时，只要你不与 origin 服务器连接，你的 origin/master 指针就不会移动。

如果要同步远程库到你的本地库，运行 git fetch命令。

git fetch 远程仓库地址 分支名

这个命令查找 “远程仓库地址” 是哪一个服务器，从中抓取本地没有的数据，并且更新本地数据库，移动 origin/master 指针指向更新后的位置。

这里使用的是：

git fetch origin master

完成后可以通过

git log -p master..origin/master

命令查看本地master分支和origin/master指向分支的区别。

此时本地仓库中的远程跟踪分支（即origin/master指针）已经完成了与远端仓库的同步。
如果此时你想在 origin/master 远程跟踪分支上工作，可以用以下代码新建分支 test 并将其建立在远程跟踪分支之上：

git checkout -b test origin/master

这会给你新建一个用于工作的本地分支 test，并且起点位于 origin/master。

---

重新回到之前步骤（git fetch之后），此时本地仓库中的远程跟踪分支（即origin/master指针）已经完成了与远端仓库的同步。
但只是远程跟踪分支完成了同步，本地分支依旧没有完成同步。 此时需要使用git merge命令来将本地分支和获取的更新后的远程分支进行最终的合并。

注意：如果你之前切换到了别的分支，请用以下命令切换回master分支：

git chekout master

处在master分支后，使用以下命令将远程跟踪分支（即origin/master指针）合并到master分支上：

git merge origin/master

合并完成后，就可以成功进行git push了！

链接本地分支和远端分支（git branch --set-upstream-to=xxx）

关联目的是在执行git pull, git push操作时就不需要指定对应的远程分支，你只要没有显示指定，git pull的时候，就会提示你。
通过以下命令实现关联：

git branch --set-upstream-to=origin/remote_branch  your_branch

origin/remote_branch是你本地分支对应的远程跟踪分支；
your_branch是你当前的本地分支。

注意：执行完上述命令后当前分支会切换为origin/remote_branch这一远程跟踪分支

在某个仓库中我们通过 git branch -vva 命令可以看到已经检出的分支和未检出的分支

代码推送到远端仓库（git push）

使用以下命令将代码推送到远端仓库：

git push 远端仓库地址 分支路径

例子：

origin 指代的是当前的 Gerrit 服务器地址 （即远端仓库地址），这行命令的意思是把 daily/0.0.1分支推送到服务器。

解决push时因缺少Change-Id报错

如果出现以下报错，根据提示不难发现是因为缺少 Change-Id：

这个时候只需要执行以上报错中提示的两条命令，然后再执行之前的 push 命令即可：

查看版本提交记录（git log）

通过以下命令，我们可以查看整个项目的版本提交记录：

git log

它里面包含了提交人、日期、提交原因等信息，得到的结果如下：
提交记录可能会非常多，按 J 键往下翻，按 K 键往上翻，按 Q 键退出查看

创建、重命名、查看、删除项目分支（git branch）

通过 Git 做项目开发时，一般都是在开发分支中进行，开发完成后合并分支到主干。
例子：
创建一个名为 daily/0.0.0 的日常开发分支，分支名只要不包括特殊字符即可。

git branch daily/0.0.0

如果觉得之前的分支名不合适，可以为新建的分支重命名，重命名分支名为 daily/0.0.1

git branch -m daily/0.0.0 daily/0.0.1

通过不带参数的branch命令可以查看当前项目分支列表（和 git branch -l 效果相同）

git branch

如果分支已经完成使命则可以通过 -d 参数将分支删除
注意：删除时不能处在被删除的分支上，需要先切换到其它分支

git branch -d daily/0.0.1

查看带有最后提交id、最近提交原因等信息的本地版本库分支列表

git branch -vv

切换分支/检出版本（git checkout）

例子：
切换到 daily/0.0.1 分支，后续的操作将在这个分支上进行

git checkout daily/0.0.1

基于当前指定区域拉取一条新分支，并切换至新分支上

git checkout -b 新分支名 区域名称

这里的区域名称可以是某个分支名。
比如 《本地分支处在非最新状态的原因分析》章节中 在origin/master 远程跟踪分支上创建的test本地工作分支。

如果不指定区域名称则会基于当前暂存区拉取一条新分支。

从本地版本库的 HEAD（也可以是提交ID、分支名、Tag名） 历史中检出 demo.html 覆盖当前工作区的文件。
如果省略 HEAD 则是从暂存区检出。

git checkout HEAD demo.html

将其它分支合并到当前分支（git merge）

默认情况下，Git 执行"快进式合并"（fast-farward merge），会直接将当前分支指向目标分支

git merge 目标分支名

使用 --no-ff 参数后，会执行正常合并，在 当前分支上生成一个新节点，保证版本演进更清晰

git merge --no-ff

将待合并分支上的 commit 整合成一个新的 commit 放入当前分支，适用于待合并分支的提交记录不需要保留的情况

git merge --squash

在没有冲突的情况下合并，不想手动编辑提交原因，而是用 Git 自动生成的类似 Merge branch 'test’的文字直接提交

git merge --no-edit

重新定义分支的版本库状态（git rebase）

作用是合并分支，这跟 merge 很像，但还是有本质区别，看下图：


只需注意一点：不要对在你的仓库外有副本的分支执行变基（rebase），一般对自己本地所在的master工作分支进行rebase。
提交代码前执行 git pull --rebase