Git

Git

概述

   Git是一个免费的、开源的分布式版本控制系统，是目前世界上最先进的分布式版本控制系统（没有之一），可以快速高效地处理从小型到大型的项目。

   本质：项目开发的管理工具，使用Git可以方便的完成团队的协作开发。以及项目开发过程中的资源管理。

Git的特点

• 最优的存储能力

• 非凡的性能

• 开源的

• 很容易做备份

• 支持离线操作

• 很容易制作工作流程

  简单来说就是：高端大气上档次！

GIT网站

   github：https://github.com/ （全球最大的开源项目网站）

   gitee：https://gitee.com/ （中国最大的开源项目网站）

集中式VS分布式

什么是集中式

   集中式开发：是将项目集中存放在中央服务器中，在工作的时候，大家只在自己电脑上操作，从同一个地方下载最新版本，然后开始工作，做完的工作再提交给中央服务器保存。这种方式需要联网，现在云开发就是这样的处理方式。简单的来说就是把所有版本代码放到一个地方管理。

   缺点：
    1. 如果网络出现异常或者很卡，直接影响工作效率。如果是中央服务器挂了，那就集体喝茶去了。

    2. 还有一种情况，各自电脑中操作的所有软件工具，都存放在一个中央服务器上（现在流行叫云服务器），只需要用各自电脑登陆连接到云服务器上，（一般服务器都是用linux），比如用ps工具，大家其实用的是云服务器中的同一个ps 软件，在使用率高的情况下，ps会出现异常，当用ps筛选颜色的时候，已经混乱，无法正常选择颜色，这个情况是我在开发中遇到的。以前我们是每个人用各自安装的ps,但是在这样的环境下用的是同一个ps软件的时候就会有 bug。

    3. 安全度不高，重要的东西都放在一个中央服务器中，如果被黑，那损失就大了。

   优点：
    减少了硬件和软件成本，硬件不用说了，现在流行盒子，一个小盒子只要连上中央服务器即可，以前都是一个个主机箱，那成本大多了。如果用到工具软件需要收费，只需买一套正版就OK了。

什么是分布式

   分布式开发：只要提供一台电脑作为版本集中存的服务器放就够了，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它也一样干活，只是交换修改不方便而已。而每一台电脑有各自独立的开发环境，不需要联网，本地直接运行，相对集中式安全系数高很多。简单的来说就是把版本代码分布到各个位置。

Git的基本使用

Git下载及安装

下载

  下载地址：https://git-scm.com/downloads

   Git所有版本：https://mirrors.edge.kernel.org/pub/software/scm/git/

检查安装是否成功

   输入【git --version】输出版本信息证明安装成功 。

   如果出现以下界面说明安装成功了（除非脸黑，否则是没有任何问题的）。

因为Git是分布式版本控制系统，所以，每个机器都必须自报家门（标识 ）：你的名字和Email地址。

git config --global user.name "用户名" 
git config --global user.email "邮箱地址" 
例：
git config --global user.name "lyang"
git config --global user.email "2411135390@qq.com"

执行完成后会在用户目录下生成一个【.gitconfig】文件。

创建版本库

什么是版本库

   版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”，所以，创建一个版本库非常简单。首先，选择一个合适的地方，创建一个空目录（例：D:git）：

  在本地创建一个目录作为git仓库，并通过git init命令进行初始化，初始化成功后会在当前目录生成一个.git目录文件，不要删除及修改。

Git常用命令集

mkdir XX         （创建一个空目录XX指目录名）
pwd     显示当前目录的路径
git init          把当前的目录变成可以管理的git仓库，生成隐藏的.git文件。
git add XX        把XX文件添加到暂存区。
git commit -m “XX”         提交文件 -m后面的是注释
git status        查看仓库状态
git diff XX       查看XX文件修改了哪些内容
git log           查看历史记录
git reset -hard HEAD^ 或 git reset -hard HEAD~      回退到上一个版本 （如果想回退到100个版本，使用git reset -hard HEAD~100）
cat XX            查看XX文件内容
git reflog        查看历史记录的版本号id
git checkout --XX          把XX文件在工作区的修改全部撤销
git rm XX         删除XX文件
git remote add origin https://gitee.com/oldlu_wk/gittest.git     关联一个远程库
git push -u         （第一次提交要用-u以后不需要）origin master把当前master分支推送到远程库
git clone https://gitee.com/oldlu_wk/gittest.git        从远程库中克隆
git checkout -b dev  创建dev分支并切换到dev分支上
git branch           查看当前所有分支
git checkout master  切换回master分支
git merge dev        在当前分支上合并dev分支
git branch -d dev    删除dev分支
git branch name      创建分支
git stash            把当前的工作隐藏起来等以后恢复现场后继续工作
git stash list       查看所有被隐藏的文件列表
git stash apply      恢复被隐藏的文件，但是内容不删除
git stash drop       删除文件
git stash pop        恢复文件的同时也删除文件
git remote           查看远程库的信息
git remote -v        查看远程库的详细信息
git push origin master    Git会把master分支推送到远程库对应的远程分支上

文件管理-添加文件

概述

   首先这里再明确一下，所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。

   不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，前面我们举的例子只是为了演示，如果要真正使用版本控制系统，就要以纯文本方式编写文件。

   因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。

相关命令

git status

  查看当前库里面有没有和本直仓库不一样的文件

git add 文件名例

  把没有添加到版本库的文件添加进入

例：git add readme.txt
#可以一次性添加多个要添加的文件

例：
$ git add file1.txt
$ git add file2.txt file3.txt

git commit -m ‘描述信息’

  把准备提交的文件正式提交到版本库

例：

git commit -m '我是一个空文件'

-m的数据如下：

git diff [文件名]

  查看当前工作区和版本库里面不一样的地方

例：

$ git diff
$ git diff readme.txt

没有提交【工作区】

已添加但未提交【暂存区】

已提交到版本库【版本库】

总结

添加文件到Git仓库，分两步：

  使用命令git add <file>，注意，可反复多次使用，添加多个文件；

  使用命令git commit -m <message>，完成。

要随时掌握工作区的状态，使用git status命令。

如果git status告诉你有文件被修改过，用【git diff】可以查看修改内容。

文件管理-版本回退

在工作区的回退

一个新的文件或者一个被修改的文件，没有添加和提交，现在就是工作区。

使用【git checkout readme.txt】撤销修改：

在版本库的暂存区的回退

先使用 【git reset [文件名] 】可以把暂存区里面的数据清空

再使用【git checkout readme.txt】撤销修改

到版本库之后的回退

只要 commit 一次就会生成一个版本。

查看版本变更记录（日志）

git log        #查看历史记录，显示从最近到最远的日志
或
git reflog     #查看简短日志

查看版本变更记录一行显示

git log --pretty=oneline

版本向上回退

向上回退一个版本

git reset --hard HEAD^

^ 代表一个版本

^^ 代表两个版本

向上回退二个版本

git reset --hard HEAD^^

  ^^ 代表两个版本

向上回退到具体版本

git reset --hard [版本号简写]

结果弊端

  1， 先使用【git reset --hard HEAD^】 回到上一个版本。

  2， 或者使用【git reset--hard [版本号(简写)]】回到指定版本号的版本。

  3， 版本号可以使用【git log】或者【git log --pretty=oneline】查看。

  4， 重新修改之后再添加和提交，只要提交了版本库里面就有记录。

工作区和暂存区

工作区

  就是我们能看到的电脑的相关目录。也就是创建文件之后没有执行任何命令的时候，那么这个文件就处理工作区。

暂存区

  当创建完文件使用【git add 文件名1文件名2】这之后那么这些文件就到暂存区。

分支区

  当使用【git commit -m ‘描述信息’】之后这暂存区里面的所有数据都会提交到当前分支 如master。

文件管理-文件修改

测试思路

1. 修改readme.txt文件

2. Git add readme.txt

3. Git commit -m ‘修改了Readme.txt’ --clean

4. 再修改readme.txt

5. Git add readment.txt

6. 再修改Readme.txt

7. 再提交

测试分析

  第一次提交只把第一次修改提交到分支。

  第二次的提交只是把第二次的修改提交到分支而第三次的修改没有被add 所有也没有被提交 。

总结

  commit 可能把暂存区里面的数据提交到分支，数据必须add 之后才能被提交。

文件管理-删除文件

直接使用【rm -rf 文件】或直接从硬盘上干掉

  这种删除方式完成之后，需要我们add一次再commit一次

使用【git rm -rf 文件】删除 （建议使用）

  使用git rm -rf 删除之后只用再commit 一次就可以了

分支管理-创建与合并分支

前面说过：当提交commit的时候是把当前暂存区里面的数据提交到当前分支。

分支的作用

1. 可以备份

2. 可以回退

3. 开发中至少有两个分支

  master ：主线版本

  dev ：开发版本线

分支的用例说明

   在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

   一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长：

   当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

   不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

   假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

   合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

真是太神奇了，你看得出来有些提交是通过分支完成的吗？

分支的操作

创建分支

git branch [分支名]
例：
git branch dev    #在master分支的基础上创建一个叫dev的分支。

查看分支

git branch     查询当前仓库的的所有分支
git branch –v

*代表当前所处的分支

切换分支

git checkout [分支名]
例：
git checkout dev   #切换到Dev分支

创建并切换分支

git checkout -b issue

合并分支

例如：A要合并B那么必须A主动 ，也就是必须在A的分支完成这个合并。

git merge [分支名]
例：
git merge dev     把dev合并到master上来

删除分支

git branch –d [分支名]
例：
git branch -d issue

命令总结

查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>

冲突的解决

如图：

如上图：

  dev 从3.0版本切出3.1.0又提到了3.1.1基本 --基础版本是3.0

master 分支从3.0升级到4.0那在master上能合并3.1.1吗？

  肯定不可，因为它们的基础版本不一样，所有当合并的时候出现 (master|merging)。

解决冲突

   例：删除4、6、9行，然后再添加，再提交。（工作中如果冲突，需和合并代码编写的人员沟通）

分支管理-分支策略说明

一般企业中开发一个项目的分支策略：

1. 主分支 master

2. 开发分支 develop

3. 功能分支 feature

4. 预发布分支 release

5. bug 分支 fixbug

6. 其它分支 other

主分支 master

   代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

Git主分支的名字，默认叫做 master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

开发分支 develop

  主分支只用来发布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。

这个分支可以用来生成代码的最新代码版本。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。

功能分支 feature

  功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。

功能分支的名字，可以采用feature-*的形式命名。

预发布分支 release

   预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面 分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。

bug分支 fixbug

   bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。

其它分支 other

还有就是其它分支了，大家可以根据需要创建即可……

总结

  在实际开发中，我们应该按照几个基本原则进行分支管理：

   首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

   那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

   你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

   所以，团队合作的分支看起来就像这样：

分支管理-Bug分支【工作现场】

  git stash 存储当前工作区的数据

  git stash list 列出之前存储的数据

  git stash pop 取出存储的数据

问题描述

  例：现在项目发布版本为1，开发人员项目到7，接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：

1. 先在dev上存储我当前的工作空间【git stash】

2. 回到master分支

3. 使用git checkout -b issue-101分支来解决issue-101的bug

4. 再切换到master分支合并issue-101

5. 再发布没有bug的版本

6. 再切换到Dev分支

7. 合并issue-101解决之前master上面的bug 因为dev分之是从有bug的master上切过来的

8. 恢复dev的工作现场

9. git stash pop 恢复

10. git stash list 查看之的现场

使用GitHub远程仓库

为什么要远程仓库

  因为做代码交互

远程库存配置

创建SSH Key。

   在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

ssh-keygen -t rsa -C "2411135390@qq.com" 

登陆GitHub，打开“Account settings”，“SSH Keys”页面：

  github网址：https://github.com/

添加远程仓库

创建一个空项目

查看提示

关联远程仓库

git remote add origin https://github.com/LYANG-HUB/demo.git
git push -u origin master

解决执行【git push -u origin master】出现HttpRequestException encountered问题

  原因：Github禁用了TLS v1.0 and v1.1，必须更新Windows的git凭证管理器。

下载地址：https://github.com/Microsoft/Git-Credential-Manager-for-Windows/releases/

推送到远程仓库

  把本地仓库master推送到远程仓库

git push -u origin master
git push -u origin dev

从远程仓库拉取

  把本地仓库删除再从远程仓库下载

Clone

例：

git clone https://github.com/LYANG-HUB/demo.git

存在问题

发面只clone了master，这是因为没关联，使用【git checkout -b dev origin/dev】

分支管理-多人协作

   在实际开发中，多个人可能开发同一个项目，使用不同的目录就可以了。

创建两个目录模拟两个程序员

  张三 李四

进入两个目录分别Clone同一份代码

  git@github.com:leijhArvin/hello1.git

测试说明

在张三里面修改readme.txt

Git add readme.txt

Git commit -m ‘张三修改提交’

Git push origin master 张三提交到远程仓库

李四的操作

修改readme.txt

Git add

Git add readme.txt

Git commit -m ‘李四修改提交’

Git push origin master 张三提交到远程仓库

   |--报错

   |--解决branch --set-upstream-to=origin/master master

李四先git pull origin master

李四解决冲突 再git add git commit git push origin master

使用码云

概述

   因为在使用github时已生成的sskey 所以在这里就不用再生成了。

配置sshkey

打开 www.gitee.com 并登陆

打开用户--->设置

创建空项目

创建本地仓库

关联远程仓库

推送到远程仓库

更新远程仓库到本地

IDEA里面使用gitee

创建一个远程的空仓库

在idea里面创建选择项目提提到本地仓库

把本地仓库提交到远程仓库

更新

创建分支

可以看到本地分支和远程分支

可以看到所处分支

分支切换

安装步骤：https://www.cnblogs.com/javabg/p/8567790.html

把远程仓库拉取到本地

解决冲突

产生冲突的原因

   冲突产生的根本原因是：两个人修改了同一个文件的同一块区域，在前者已经提交代码到远程仓库的情况下，后者修改代码前没有使用pull命令更新代码，而是修改完代码后再使用pull命令，这时就会产生冲突。这也是最常见的冲突，下面介绍解决冲突的办法也主要针对这种冲突。

预防冲突

   在修改代码前，使用pull命令更新代码，能够保证在开始修改代码前本地的代码与远程仓库中的版本一致，这样能够大大降低冲突发生的概率。

解决冲突

  按照图片中的步骤，顺序不能乱，先stash，然后pull，最后unstash

   第一步：暂存代码，idea会恢复到上次更新后的代码，将修改的代码隔离出去

   第二步：将远程仓库的代码拉下来

   第三步：将暂存的代码还原回来

从左至右

1. 本地代码更新后的代码

2. 合并后的代码

3. 暂存文件的代码