万字长文，手把手教你玩转Git！

项目已托管到GitHub，你们能够去GitHub查看下载！并搜索关注微信公众号 码出Offer 领取各类学习资料！

Git应用

---

1、初识Git

1.1 Git的简史

同生活中的许多伟大事物同样，Git 诞生于一个极富纷争大举创新的年代。

Linus在1991年建立了开源的Linux，Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工做都花在了提交补丁和保存归档的繁杂事务上（1991－2002年间）。 到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。 到了 2005 年，开发Samba的Andrew试图crack BitKeeper的协议，随后开发 BitKeeper 的商业公司同 Linux 内核开源社区的合做关系结束，他们收回了 Linux 内核社区无偿使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，Linus仅仅使用了两周的时间用C写出了Git，开发出本身的版本系统，一个月以内，Linux系统的源码已经由Git管理了。 他们对新的系统制订了若干目标：

• 速度
• 简单的设计
• 对非线性开发模式的强力支持（容许成千上万个并行开发的分支）
• 彻底分布式
• 有能力高效管理相似 Linux 内核同样的超大规模项目（速度和数据量）

自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。 它的速度飞快，极其适合管理大项目，有着使人难以置信的非线性分支管理系统。Git迅速成为最流行的分布式版本控制系统，尤为是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub。

这时候是否是有不少小伙伴已经被Linus所惊讶到了呢？使用了两周时间用C写出了Git！

1.2 Git究竟是什么？

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

1.3 什么是版本控制系统？

版本控制是指对软件开发过程当中各类程序代码、配置文件及说明文档等文件变动的管理，是软件配置管理的核心思想之一。

1.3.1 版本控制系统的做用

版本控制最主要的功能就是追踪文件的变动。它将何时、什么人更改了文件的什么内容等信息忠实地了记录下来。每一次文件的改变，文件的版本号都将增长。除了记录版本变动外，版本控制的另外一个重要功能是并行开发。软件开发每每是多人协同做业，版本控制能够有效地解决版本的同步以及不一样开发者之间的开发通讯问题，提升协同开发的效率。并行开发中最多见的不一样版本软件的错误(Bug)修正问题也能够经过版本控制中分支与合并的方法有效地解决。

版本控制系统不只为咱们解决了实际开发中多人协同开发的问题，还提供了一些功能：检入检出控制 、分支和合并 、历史记录

• 检入检出控制：同步控制的实质是版本的检入检出控制。检入就是把软件配置项从用户的工做环境存入到软件配置库的过程，检出就是把软件配置项从软件配置库中取出的过程。检人是检出的逆过程。同步控制可用来确保由不一样的人并发执行的修改不会产生混乱。
• 分支与合并：版本分支（以一个已有分支的特定版本为起点，可是独立发展的版本序列）的人工方法就是从主版本——称为主干上拷贝一份，并作上标记。在实行了版本控制后，版本的分支也是一份拷贝，这时的拷贝过程和标记动做由版本控制系统完成。版本合并（来自不一样分支的两个版本合并为其中一个分支的新版本）有两种途径，一是将版本A的内容附加到版本B中；另外一种是合并版本A和版本B的内容，造成新的版本C。
• 历史记录：版本的历史记录有助于对软件配置项进行审核，有助于追踪问题的来源。历史记录包括版本号、版本修改时间、版本修改者、版本修改描述等最基本的内容，还能够有其余一些辅助性内容，好比版本的文件大小和读写属性。 若是咱们开发中的新版本发现不适合用户的体验，这时候就能够找到历史记录的响应版本号，回退到历史记录版本！

1.4 版本控制系统的分类（了解）

常见流行的分布式版本控制管理系统有Git

常见流行的集中式版本控制管理系统有CVS、SVN

代	网络	操做	并发性	示例
第一代	无	仅一个文件	锁定的	RCS、SCCS
第二代	集中式	多文件	提交以前合并	CVS、SourceSafe、Subversion、Team Foundation Server
第三代	分布式	变动的集合	合并以前提交	Bazaar、Git、Mercurial

1.5 分布式与集中式

1.5.1 集中式

集中式系统是指由一台或多台主计算机组成的中心节点，数据集中存储于这个中心节点中，而且整个系统的全部业务单元都集中部署在这个中心节点上，系统的全部功能均由其集中处理。

简单提了集中式的概念，那集中式版本控制也是如此。如图，咱们须要合并版本、更新版本时，是将各个版本上传服务器实现集中式合并！

举例来讲，集中式版本控制系统在公司中的使用，须要安装一个Server（服务器），而后各个使用版本控制系统的成员安装客户端，而后就是客户端链接服务器了，只有脸上这个服务器才能作版本控制，若是连不上那就不行了。

工做流程： 比较熟悉的SVN是集中式的版本控制系统，每次在进行版本控制以前，须要先从中央服务器（服务端）取出最新的版本，而后开始工做，工做完后推送给中央服务器。此时的中央服务器就比如是一个图书馆，若是你要修改一本书，须要先从图书馆借出来，而后回到本身家修改，改完以后，须要在送回到图书馆。

1.5.2 分布式

分布式系统是一个硬件或软件组件分布在不一样的网络计算机上（本地化存储），彼此之间仅仅经过消息传递进行通讯和协调的系统。

又一次简单提了分布式的概念，那分布式版本控制更是如此。如图，咱们须要合并版本、更新版本时，各台计算机均可以去实现彼此之间合并、更新，再也不只依赖于一个中心节点，为咱们开发提供了灵活与便捷！

举例来讲，分布式版本控制系统在公司中的使用与集中式不一样，各个成员须要安装一个Git客户端，而各个成员之间能够随时随地的实现版本控制（好比：两我的合并后，再与第三我的合并或者小组与小组之间合并进行版本控制），再也不依赖于必须链接服务器才能实现，那么咱们实现了各个小组之间的灵活控制后，最终仍是得落到了服务器的手中。咱们须要把各个成员、小组之间的版本控制结果，上传到服务器（GitHub）中进行最终合并！

工做流程： 分布式版本控制系统是没有“中央服务器”，每一个人的电脑上都是一个完整的版本库，工做的时候，再也不须要联网。开始工做前，在客户端克隆出完整的代码仓库，而后就能够在家、在公交车等等为所欲为地修改代码并提交了，提交到本地电脑，等到有网的时候就能够一次性地将本地仓库推送到远端仓库（临时中心服务器）中，这样一来，每一个人均可以独立进行改动资料，而且全部的改动都是在完整资料信息的环境下进行的。

1.5.3 分布式与集中式的区别

集中式

• 有一个单一的集中管理的服务器，保存全部文件的修订版本，全部代码库。
• 对网络的依赖性强，必须联网才能工做，上传速度受网络情况、带宽影响。
• 客户端记录文件内容的具体差别，每次记录有哪些文件作了更新，以及更新了哪些行的什么内容。

缺点： 中央服务器的单点故障。 若是中央服务器发生宕机，全部客户端将没法提交更新、还原、对比等，也就没法协同工做。若是磁盘发生故障，信息尚无备份，还会有数据丢失的风险。

分布式

• 本地客户机进行操做，离线工做，快速。
• 安全性高，每一个人电脑里都有完整的版本库，若是电脑发生了更换复制一份就能够。
• 原子性提交，提交不会被打断（git）。
• 工做模式很是灵活（传统的集中式工做流 + 特殊工做流 + 特殊工做流和集中式工做流的组合）。

缺点： 缺乏权限管理、命令复杂混乱

1.6 Git的下载安装

Git官网下载：git-scm.com/

TortoiseGit官网下载：tortoisegit.org/

Git文档下载：git-scm.com/book/zh/v2

Git详细安装教程参考：blog.csdn.net/weixin_4417…

注意： 关于Git的可视化工具下载与否取决于本身，笔者不建议下载可视化工具，由于咱们要大量使用并熟练使用命令来操做Git！

Git客户端下载	Git可视化工具下载

1.7 安装后测试

1.7.1 打开命令的两种方式

1. Wins+R输入cmd打开Dos命令窗口
2. 右键单击打开Git Bash Here窗口

1.7.3 命令查看Git版本号

@查看Git版本号： git version

1.7.2 提交版本控制人信息

安装后打开命令窗口，第一次须要提交咱们的信息，这样可让咱们在版本控制的时候知道是谁作的这一次的版本控制。毕竟合并、更新代码等是一件很重要的事，万一缺失损坏了怎么办呢？是吧！

@提交信息版本操做者信息：

git config --global user.name "Ziph" 【用户名】

git config --global user.email "mylifes1110@163.com" 【邮箱】

@查看信息：

git config -l

2、仓库

2.1 仓库是什么？

版本库又名仓库，英文名repository，你能够简单理解成一个目录，这个目录里面的全部文件均可以被Git管理起来，每一个文件的修改、删除，Git都能跟踪，以便任什么时候刻均可以追踪历史，或者在未来某个时刻能够“还原”。

2.2 基本结构

工做区： 由咱们使用命令git init初始化的一个本地文件夹，而初始化后的这个文件夹就被称为工做区

暂存区： 由咱们使用命令git add .把文件添加到暂存区，而被添加的位置则是工做区中.git目录中的index文件，因此这也叫作索引

版本库： 工做区中会有一个隐藏的.git文件夹，这个不算是工做区，而是Git的版本库，版本库中记录了咱们提交过的全部版本，也就是说版本库管理着咱们的全部内容

分支： 版本库中包含若干分支，提交后的文件就会存储在分支中，而开始的时候版本库中只会有一个主分支master

基本结构
工做区-版本库-暂存区-分支

2.3 仓库基本命令操做

咱们在使用git来管理本地仓库时，每次对工做区中的内容作的任何变化都须要add（添加）和commit（提交）操做来同步git版本库，只有作了添加和提交操做git才能管理咱们的工做区。

@建立版本库： 建立或找到一个文件夹，打开命令窗口，执行git init初始化本地工做区，在该工做区内会初始化生成一个.get目录，而该目录就是版本库，它保存着仓库的全部信息

@添加一个文件： 在工做区中放入一个文件，而后在命令行窗口中执行git add 文件名便可向工做区中添加一个文件

@添加多个文件： 在工做区中放入多个文件，而后在命令行窗口中执行git add 文件名1 文件名2 ...便可向工做区中添加多个文件

@添加文件夹内容： 在工做区中放入一个文件夹，然而文件夹中有不少文件，打开命令行窗口执行git add 文件夹名便可向工做区中添加该文件夹以及文件夹内的全部内容

@添加工做区内全部内容： 若是工做区中有不少文件夹和文件，咱们一个或多个添加很麻烦，咱们可使用git add .命令来添加工做区中的全部内容

@提交某些文件： 使用git commit 文件名1 文件名2 -m "本次提交的描述信息"，注意提交的描述信息是为了记录本次提交而方便查找，因此尽可能能明确反映本次提交

@提交全部文件： 使用git commit -m "本次提交的描述信息"命令来提交文件，提交后的文件就由git来管理了。-m 后面双引号中的内容，这描述此次提交的信息，以便之后咱们后续找到此次提交再作操做

@修补提交： 提交后发现有问题，好比释忘记修改，⽐如提交描述不够详细等等。咱们能够执行git commit --amend -m"描述信息"来再次提交替换上次提交

@添加并提交文件： 使用git commit -a -m "本次添加并提交的描述信息"命令来自动添加和提交全部文件

@删除文件： 使用命令git rm 文件名来删除文件，并使用git commit 文件名 -m "描述信息"来提交此次删除的文件（了解便可）

@文件删除和修改： 关于向git提交后的文件，删除和修改咱们只须要从新提交便可。也就是说，咱们挪动或删除了工做区中的文件或更改了工做区中的目录结构，都须要从新向git添加和提交你所变更的文件。

@文件状态： 关于如何查看咱们添加或提交了哪些文件、仍是只添加了文件没有把它提交。查看文件状态须要使用git status命令查看文件的状态

@查看该文件的改动状况： 使用git diff 文件名命令来查看该⽂件的改动状况

@帮助： 使用git help commit或者git commit --help来获取命令的提示帮助

2.4 日志命令操做

咱们的每次提交，git都会随着提交的变更来记录版本变化，因此你在工做区中的全部操做都会留下日志。

@查看全部提交日志： 使用git log命令来显示从最先的提交点到当前提交点的全部日志

@查看执行条数的提交日志： 使用git log -数量命令来显示最近指定数量条的提交日志

@简洁日志显示： 使用git log --oneline命令来显示比较简洁的提交日志

@查看最近的2次提交日志： 使用git log --oneline -数量命令来简洁的显示最近的数量条的提交日志

@图形化显示分支走向： 使用git log --oneline --graph命令来图形化显示分支走向

提交ID： git中的commitID是经过SHA1计算出来的⼀个⾮常⼤的数字，⽤⼗六进制表示，在分布式中保证惟一性。

而关于日志中显示的commitID，使用git log命令显示的提交ID是很长的字符串，而使用git log --oneline命令来简洁显示的提交ID是一个7位的字符串。若是咱们后续在使用commitID来操做的时候能够指定提交ID的前几位字符便可，只要在你所操做的几条commitID前几位字符不发生重复就可使用，因此在咱们使用ID的时候并不须要使用很长的ID来操做，而通常使用前7位

查看日志

2.5 版本回退命令操做

每次修改文件并添加和提交。git都会记录一个版本，若是有须要能够回退到以前的数据版本状态

@回退上一个版本： 使用git reset --hard HEAD~命令来回退到上一个版本

@回退上上个版本： 使用git reset --hard HEAD~~命令来回退到上上个版本

@回退到上某数量个版本： 使用git reset --hard HEAD~数量命令来回退到上某数量个版本

@回退到某次提交时的版本： 使用git reset --hard commitID命令来回退到某次提交时的版本

注意： 回退的版本指定的commitID假如是22c4302cc866fbf5a3184b1fea6bd90b8c85255f，此时咱们可使用命令git reset --hard 22c4302来回退到该提交ID时的版本，虽然commitID这么长，咱们只须要保证惟一性来输入前几位commitID便可。要记住回退版本并不会删除任何版本，因此版本之间能够来回切换

@细节： 发⽣版本回退后，经过git log命令只能看到最原始提交点⾄当前提交点的⽇志。而git reflog能够看所有⽇志（包括版本回退的日志）

2.6 文件状态

切换至某个分支，在工做区操做该文件，文件状态会有如下几种：

文件状态	描述
未跟踪	⼯做区中新建立的⽂件，git中并未保存它的任何记录。使用git add .命令添加至暂存时便可创建跟踪状态
修改	已跟踪状态的文件，在工做区被修改了，则会变为修改状态
暂存	使用git add .命令添加到暂存区的文件处于暂存状态。每次暂存的是文件的当前状态，若是文件被修改过，则须要再次将该文件添加到暂存区。而每次提交，是将全部暂存区的文件提交
提交	使用git commit -m "描述"命令来提交文件，则该文件就将从暂存状态变为了已提交状态。每次提交，会增长一个版本，分支指针后移指向新版本

2.7 查看文件状态

咱们可使用git status命令来时刻查看文件所在状态

@细节： 可使用git diff命令来比对工做区内文件的变更状态

@比对： 使用git diff 文件名命令来比对工做区和暂存区（若暂存区没有则比对分支）

@比对工做区与分支的最新结果： 使用git diff HEAD -- 文件名命令来比对工做区和分支的最新结果

@比对暂存区与分支的最新结果： 使用git diff --staged 文件名命令来比对暂存区与分支的最新结果

注意： git diff HEAD -- 文件名命令--与文件名之间必需要有一个空格，不要写错！

无文件放入工做区、无add、无commit（没有任何文件状态）
将一个名为test.txt文件放入工做区、无add、无commit（未跟踪状态）
将test.txt文件add到暂存区、无commit（暂存状态）
将test.txt文件commit提交到master主分支（提交状态）
修改test.txt文件内容、无add、无commit（修改状态）
将处于修改状态的文件add并commit提交后再次查看文件状态就无任何文件状态了！

2.8 撤销修改命令操做

@工做区撤销： 执行git checkout -- 文件名命令能够撤销到最近一次git add或git commit的状态

工做区撤销内部流程： 你执行了工做区撤销命令，若是暂存区有此文件，则将暂存区中的文件恢复到工做区中；若是暂存区没有此文件，则将分支中的文件恢复到工做区中

@暂存区撤销： 先执行git reset HEAD 文件名命令将该文件移除暂存区，后执行git checkout -- 文件名命令回退到上一个版本

暂存区撤销场景： 若是在工做区中修改了文件并发送到了暂存区中，但文件中有须要撤销的内容

3、分支

3.1 分支概述

• 每个被git管理的仓库都会有一个默认的主分支（master分支）
• 分⽀中接收git commit提交的内容，为⼀个⼀个不断向前发展的提交点。每一个提交点都保存了⼀个版本
• 每一个分⽀，都有⼀个指针，指针默认指向最近⼀次提交的版本
• ⼯做区中的内容，初始状态，就是指针所指向的版本状态
• 基于指针指向的版本代码，在⼯做区中作进⼀步的编码，功能完成后，便可git commit，在分⽀中造成新的提交点。而后再在⼯做区中，添加新代码，功能完成，再 git commit,⼜造成新的提交点，指针再次后移。如此反复，不断开发，不断记录版本。
• 当有须要时，能够回退指针到某个提交点，在⼯做区中便可获得以前的某个版本的代码

分支效果图

3.2 多分支

为何要使用多分支呢？那么咱们就须要了解几个场景了

场景1： 在编写一个功能代码时，须要一周的时间，在一周时间内可能会有屡次提交，但最后的时候咱们中间提交点的代码中发现有问题存在，那这些存在问题的提交点就掺杂在master主分支，使主分支变得十分混乱

场景2： 在编写一个功能代码时，有一个新的思路，但不肯定可否最总实现预期功能效果，只能试着编写，最后发现达不到预期功能结果，则中间提交过的不少提交点都无效了，也使得主分支变得十分混乱

场景3： 若是该项目是多人协同开发，master主分支有错误或无效的提交点会影响其余人的开发进度

注意： 实际开发中master分⽀尽可能只存放稳定的代码提交，保证master分⽀稳定，有效。由于这样保证了咱们的开发进度不会受到影响

解决方案1： ⼀直不提交，等全部都写完后，提交⼀次。虽然能够保护master分⽀，但开发过程当中缺少版本控制点，易丢失⼯做

解决方案2： 在须要编写新功能时，新建⼀个开发⽤的分⽀，全部改动都在该分⽀上提交，在功能完整实现后，将该分⽀的最终内容合并到master分⽀。这样，既保证开发中有多个版本能够控制，⼜保证master分⽀是稳定，有效的

多分支效果图

3.3 多分支基本命令操做

@建立分支： 使用git branch 分支名命令建立分支，会与当前分支保持一样的数据状态，即新分支和当前分支指向同一个提交点

@切换分支： 使用git checkout 分支名命令切换分支，切换分支后工做区中显示当前分支内容（切换分支其实是切换了分支的指针，让指针指向了所要切换到分支）

@查看当前分支： 使用git branch命令来查看当前分支

@查看当前分支详细信息： 使用git branch -vv命令查看分支详细信息，分支信息则是所跟踪的远程分支信息以及是否领先远程分支等等

@合并分支： 若是新分支编写完成后，先使用git branch master命令切换到master分支，再使用git merge 新分支名命令将新分支合并到master分支。这次合并就是将master的指针移到了新分支的位置，等价于快速合并 @查看当前合并分支： 分支合并后可使用git branch --merged命令查看被当前分⽀合并了的分⽀

@删除分支： 将分支合并后，若是新分支再也不继续使用，能够先使用git branch --merged命令查看合并分支以确认咱们即将删除的分支的确是无用分支后，再使用git branch -d 分支名命令删除须要删除的无用分支。

3.4 解决分支冲突

场景： 建立一个新分支（见图1）；切换到新分支，并在文件中添加一些信息并提交（见图2）；切换到master分支，并在文件中也添加一些信息并提交（见图3）；在master分支中合并新分支。此时合并分支中会出现冲突（见图4）

分支冲突缘由： 两个分支对同一个文件作了改动，因此在合并时git会没法肯定保留哪一个分支上的数据

@终止合并分支： 当出现分支冲突时可使用git merge --abort命令来终止合并分支

@避免由于空⽩致使冲突： 在合并分支时，若是有空白内容有可能会出现分支冲突现象，因此此时可使用git merge 分支名 -Xignore-all-space命令来避免由于空白而致使的分支冲突

解决分支冲突： 须要找到提交两个分支的人一块儿讨论最终保留哪些数据，讨论后将最终要保留的数据在一个的分支中提交。此时便解决了合并时发生的分支冲突问题，合并完成后某个分支将再也不使用可使用git branch -d 分支名命令来删除无用分支

注意： 解决冲突要么保留其中的一方，要么达成协议商讨双方手动合并，不管如何记得删除<<<< ==== >>>> 这些符号

分支冲突效果图
分支冲突错误提示信息：
Auto-merging test.txt CONFLICT (content): Merge conflict in test.txt Automatic merge failed; fix conflicts and then commit the result.
合并冲突后git将双方对文件的改动都保留了，并使用<<<<、======、>>>>>作了分隔

3.5 快照

git在保存每一个版本时( 对应提交点 )，并非复制全部⽂件，没有改动的⽂件只是记录⼀个连接。

解释： 首先看V1版本内有三个文件。咱们将A、C文件作了修改并提交便生成了V2版本。这时内部是怎么操做的呢？其实git在内部复制了A、C两个须要修改的文件到V2版本中并作了修改，而虚线框中的B文件并无发生任何修改，其git内部就以连接的形式在V2版本用引用了B文件，减小了重复文件的环节，大大提升了Git的效率。以此类推，之后的版本虚线框内也都是引用的上个版本的文件

快照效果图

3.6 合并方式

分支的合并方式有两种快速合并 和三方合并

• 快速合并内部流程： 一我的在主分支上拉出了一个新分支为newBr并提交了一次（移动了一次指针）。若是合并这两个分支，在快速合并中只须要移动master分支的指针指向newBr分支便可实现合并
• 三方合并内部流程： 在三方合并中从开始分叉的那个提交点开始，分别将该提交点更新的部分数据合并至master和newBr分支，合并后就三个分支就剩下了俩个分支。则剩下的master分支和newBr分支将合并为一个新的提交点，而这个由三方合并成的新提交点为最终合并成功的那个master分支

注意： 如下例图并不严谨，只为传达思想！

快读合并效果图
三方合并效果图

4、远程仓库（Github）

4.1 获取SSH key

git本地仓库和GitHub或码云之间传输，建议设置SSH key，避免在传输中反复输入密码

设置SSH key： 执行ssh-keygen -t rsa -C "邮箱"命令后的每一步都按Enter键肯定就好，知道命令执行结束（-C 后面的内容随意写就行，这只是做为title而已）

命令执行完毕后，会在你电脑的C:\Users\主机名\.ssh目录下生成密钥文件。id_rsa是私钥，不能泄露出去。id_rsa.pub是公钥，能够放⼼地告诉任何⼈。

随后注册登陆GitHub，在帐户设置中选择SSH Keys，在Title中随意填写内容，在Key中填写id_rsa.pub文件中的全部内容

在GitHub中添加好本身的公钥，这样和Git服务器通讯时（clone，push，pull）git服务器就能够识别出你的身份了！

4.2 注册登陆并设置SSHKey

GitHub官网地址： github.com/

注册GitHub帐号（Sign up）
登陆GitHub（Sign in）
右侧头像点击打开Setting设置
在Setting中建立SSH Key
添加SSH Key

4.3 建立远程仓库（主四步骤）

首先在GitHub中建立远程仓库，其次就是将本地仓库关联到远程仓库，这里若是作关联的话是须要执行一些命令的，虽然在GitHub建立仓库的时候已经提示命令，可是因为我想到有不少小伙伴会不清楚怎么看和执行这些命令，因此我在图中已经标注。为了全面些，我也会把这些命令罗列到下方并做以解释！

1. @添加自述文件： 若是是本地仓库是空的，咱们须要建立一个自述文件（README.md），也就是说建立一个文件放入到本地仓库中，执行git add .和git commit -m "add a README.md"（最好仓库中不是空的！）

2. @关联远程仓库： 关联远程仓库只须要执行git remote add 关联别名 仓库地址命令便可（注意：别名是能够本身取名设置的，可是不要忘记就好，由于后续push的时候会用到）

3. @上传到GitHub远程仓库： 执行git push 关联别名 master命令将文件上传到GitHub服务器的主master分支

4. 上传到GitHub远程仓库后，咱们就能够正常的在GitHub查看所上传的文件。设置一次关联后，咱们在本地仓库上传到GitHub远程仓库都须要add -> commit -> push

@查看关联的全部远程仓库： 执行git remote -v命令查看关联的全部远程仓库

@查看关联后远程仓库分支和本地仓库分支的对应关系： 执行git remote show 关联别名命令查看

@删除关联： 执行git remote remove 关联别名命令删除关联

@重命名关联别名： 执行git remote rename 原关联别名 新关联别名命令重命名关联别名

右侧头像点击 + 后打开New repository
建立仓库
本地仓库关联GitHub服务器
作完以上步骤就能够在GitHub上看到咱们所上传的文件了！

4.4 上传命令操做（push）

将本地仓库的文件上传到关联的GitHub远程仓库中显示（注意：push的文件是必须commit提交过的！）

将本地仓库的文件上传到关联的GitHub远程仓库中显示（注意：push的文件是必须commit提交过的！）

push操做须要关联仓库，也就是说必须有权限来对GitHub远程仓库作操做，并且须要在你pull以后没人push过

@上传到GitHub远程仓库： 执行git push 关联别名 master命令来将本地仓库的文件上传到GitHub远程仓库显示（注意：咱们是能够指定上传的分支的！）

@本地存在分支上传GitHub分支： 执行git push 关联别名 本地仓库分支:GitHub仓库分支命令会将本地仓库存在分支上传到GitHub分支

@本地存在多分支上传到GitHub多分支： 执行git push 关联别名 本地仓库分支1:GitHub仓库分支1 本地仓库分支2:GitHub仓库分支2命令来实现一次性实现上传指定多个分支

4.5 拉取远程操做（fetch、merge）

拉取远程仓库的新内容到本地仓库和版本库，可是这个操做并无合并到本地库的分⽀中，须要经过⼿动合并分支来实现。此操做并不经常使用，了解便可！

@拉取远程仓库分支： 执行git fetch 关联别名 master命令来拉取master分支下的内容

@手动合并本地库分支： 执行git merge 关联别名/master命令来手动合并本地库分支下的内容

上面两个命令能够将GitHub服务器上的最新状态同步到本地仓库中

@拉取全部分支： 执行git fetch 关联别名命令来拉取GitHub服务器全部分支下的内容（合并分支以下）

@手动合并全部分支内容： 执行git checkout 分支1命令来切换分支并执行git merge 关联别名/分支1合并拉取该分支的内容，并以此类推合并各个分支

@比较拉取内容中的分支和本地分支中的不一样： 首先执行git checkout 分支命令来切换到想要比较并拉取的分支，再执行git diff 关联别名/分支命令来比较拉取的内容中的分支和本地分支的不一样

4.6 下载操做（pull）

首先下载操做等价于拉取远程的新内容，并合并到当前分支的操做

@下载远程内容： 能够执行git pull 关联别名 master命令来完成对远程仓库主分支内容的下载操做，该操做省略了本地仓库分支（当前分支），默认的将远程仓库master主分支上的内容下载到了本地仓库的master主分支

@下载远程内容的完整写法： git pull 关联别名 远程仓库分支:本地仓库分支（当前分支）

4.7 克隆操做（clone）

将GitHub远程仓库的全部内容下载到本地，该方式自动搭建了本地与GitHub远程仓库的关联

@clone操做1： 执行命令git clone SSH地址将远程仓库clone到本地，已设置key，不用命令

@clone操做2： 执行命令git clone HTTPS地址将远程仓库clone到本地，该方式须要输入GitHub口令

细节1： clone只在初次从git服务器下载项⽬时执⾏⼀次，后续在须要同步应该执⾏pull或fetch

细节2： 当执⾏git clone命令时，默认配置下远程 Git 仓库中的每⼀个⽂件的每⼀个版本都将被拉取下来

5、标签

5.1 为何要打标签

其实在咱们作项目的时候是少不了碰见不少问题的，有可能在这个版本的问题发布出现了问题，可是到了后面的几个版本都没有获得解决。而项目每每不会由于这些问题而终止项目的上传。为了让全部人能了解该版本中的问题而使用标签做为标记

注意： 如下所使用的v1.1.0等等标签是标签名，小伙伴们能够根据本身的需求来打标签

5.2 打标签

@建立轻量标签： 使用git tag v1.1.0命令来建立轻量标签

@建立附加备注的轻量标签： 使用git tag -a v1.1.1 -m "说明文字"命令来建立附注标签，而建立标签会自动打在最近的提交点上

@为之前的提交点打标签： 若是为之前的提交点打标签就须要使用git log命令去查看commitID，再根据commitID执行git tag -a v1.1.1 "commitID"来为该提交点打标签

5.3 查看标签

@查看全部分支上的全部标签： 执行git tag命令来查看

@查看标签名以“v1.1”开头的标签： 执行git tag "v1.1*"命令来查看

@显示标签及其对应的提交信息： 执行git show v1.1.0命令来显示标签及其对应的提交信息

5.4 共享标签

标签不会随提交点⼀起 提交到远程服务器，须要单独push。而pull时，标签会⼀同被下载到本地

@同步一个标签“v1.1.1”到GitHub服务器： 执行git push 关联别名 v1.1.1命令来同步标签

@同步全部标签到GitHub服务器： 执行git push 关联别名 --tags命令来同步全部标签

5.5 删除标签

标签删除须要在本地和远程分别删除

@在本地删除标签： 执行git tag -d v1.1.1命令来删除本地标签

@删除远程库中的标签： 执行git push 关联别名 :refs/tags/v1.1.1命令来删除远程库中的全部标签

5.6 标签的使用

标签的主要做用是用于发布版本，假设咱们已经为各个版本打了标签“v1.0”、“v2.0”等等。如今须要v1.0版本，就能够分离一个指针指向v1.0版本的提交点位置

@原分离头指针： 执行git checkout v1.0版本的commitID命令来使头指针指向该commitID的提交点

@标签分离头指针： 执行git checkout v1.0命令来使头指针 指向该提交点

注意： 分离头指针只是一个临时指针，它不归属任何分支，使用标签显然比使用commitID方便，最后随意切一个分支，分离头指针消失，就像以前什么都没有发生过同样

6、别名

有一些指令感受会比较麻烦，就能够定义别名来执行命令，简化书写。下面列举一个经常使用的命令来实现别名的简化

@简化commit命令书写： 执行git config --global alias.comt "commit -m"命令来简化commit -m命令，设置这种简化命令以后之后执行git comt "描述信息"命令就等价于执行了git commit -m "描述信息"命令

@删除别名简化： 执行git config --global --unset alias.comt命令来删除咱们建立的简化commit的别名，删除后使用comt则就会失效

7、IDEA关联Git

7.1 关联Git

设置关联Git

7.2 建立仓库

在IDEA中建立仓库以前，咱们须要建立设置一个忽略文件（.gitignore）。至于为何呢？那是由于咱们在项目中会有不少文件没必要上传，就好比db.properties配置文件、.idea文件、全部的.class文件等等，因此这个忽略文件就能够帮咱们在上传服务器的时候忽略这些没有必要的文件，忽略后的文件不会放在版本库中管理

设置忽略文件
初始化一个仓库

7.3 提交

选择提交菜单，提交一个版本

选择提交文件，定义提交信息
以后会有些友好提示，能够忽略，点击“commit”便可

7.4 建立分支

点击右下角连接，建立新分支
新建分支
查看当前分支

7.5 上传到远程仓库

先建立一个仓库，随后选择push菜单
定义远程仓库地址
开始push操做
push成功后 ，弹窗提示

7.6 复制到本地仓库

找到GitHub或码云上的开源项目后复制连接，点击克隆菜单
输入如远程仓库地址
打开项目
打开项目，选项

7.7 更新本地项目

注意：若是远程仓库有更新，则你的本地项目也须要一块儿更新。

选择pull菜单
执行pull操做
更新日志显示

7.8 IDEA中冲突解决

冲突出现，弹窗中能够选择以下
也能够直接修改冲突文件，而后commit便可

8、多人协同开发

8.1 项目经理

1. 由项目经理负责建立一个远程仓库，初始仓库中什么都没有，而库的名称建议和项⽬同名
2. 管理员会在IDEA中建立⼀个空项⽬，其中包含 .gitignore⽂件 。并在项⽬根⽬录下执行git init建⽴本地库，并建⽴dev开发分⽀
3. 管理员将本地库同步到远程库，执行命令git push 远程库地址 master:master dev:dev操做
4. 将项目组中的其余人员拉入远程仓库的开发人员列表中，此操做是赋予开发人员对远程仓库push等等的权限
5. master分⽀设置为 protected分⽀，只有管理员有权限将代码合并到其中。dev分⽀设置为 常规分⽀全部开发⼈员均可以其中合并代码

注意： 管理员拉开发人员进入开发人员列表在仓库的设置中设置

8.2 开发人员

1. 开始的时候开发人员须要将项目使用IDEA或命令行clone远程仓库，获取项目。clone操做自动关联远程仓库并创建了本地仓库
2. 得到项⽬时，本地库中只显示master分⽀，须要执⾏git checkout dev便可得到dev分⽀
3. 后续的开发中，都要在dev分⽀上进⾏。开发完⼀个功能并测试经过后就能够git add .并git commit -m "描述信息"提交到本地的dev分⽀中，而后git push远程库地址的dev分支并同步到远程dev分⽀中
4. 若是在git push远程库时，有⼈⽐你早⼀步git push，GitHub服务器将拒绝你的git push操做。（乐观锁原理）不过很简单，你须要先git pull远程库的dev分支后再git push便可