来都来了，你确定不看看，Git从零开始的详细使用教程，你一定能学废（图文并茂版）_git init 会把我原本的git删掉吗

认识Git

       •Git属于分布式版本控制系统（Distributed Version Control System，简称 DVCS）在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照， 而是把代码仓库完整地镜像下来，包括完整的历史记录。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份

       •不仅如此，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。这样一来，你就可以在同一个项目中，分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程

Windows安装Git

       一、使用官方版本安装：
              •官方版本可以在 Git 官方网站下载。 打开https://git-scm.com/download/win，选择对应的版本安装！！！

       •下载完成后，安装提示一步一步安装即可！！！
       二、Chocolatey 自动安装：
              •如果要进行自动安装，你可以使用 Git Chocolatey 包。 注意 Chocolatey 包是由社区维护的，Chocolatey官网：https://chocolatey.org/
              •安装好 Chocolatey 后，执行下述命令即可：

choco install git.install
1

Git环境配置

       •好了，当你当完成了 Git 的安装后，接下来我们就需要对 Git 进行一些必要的环境配置
       •通常情况下，每台计算机上只需要配置一次 Git，当 Git 程序升级时会保留配置信息。 当然，你也可以在任何时候再次通过运行 git config命令来修改它们

用户名与邮箱地址的设置

       •Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量
       •安装完 Git 之后，要做的第一件事就是设置你的用户名和邮件地址。 这一点很重要，因为每一个 Git 提交都会使用这些信息，它们会写入到你的每一次提交中，不可更改：

git config --global user.name "ycx"  #引号中是你需要使用的用户名
git config --global user.email xxx.qq.com # 填写自己的邮箱地址
1
2

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

git config user.name "ycx"  #引号中是你需要使用的用户名
git config user.email xxx.qq.com # 填写自己的邮箱地址
1
2

       •可以通过输入 git config < key >： 来检查 Git 的某一项配置，例如：

git config user.name
git config user.email
1
2

       •也可使用下述命令，查看全部配置信息：

git config --list
1

Git中实用的自定义配置

       •让 Git 显示颜色，会让命令输出看起来更醒目：

git config --global color.ui true
1

Git忽略某个或某类文件

       •有些时候，你必须把某些文件放到 Git 工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件等等，每次git status都会显示Untracked files …，这种情况下，就可以实用忽略特殊文件.gitignore 来很方便的解决这个问题。
       •首先我们在 Git 工作区的根目录下创建一个特殊的** .gitignore文件**
       •.gitignore文件需要在Git命令行中使用touch .gitignore新建

       •然后把要忽略的文件名填进去，Git 在每次进行提交的时候就会自动忽略这些文件：
       •使用git status查看文件状态，发现practice.docx文件未被隐藏：


       •然后在**.gitignore文件**中添加practice.docx文件名，即可忽略此文件！！

       •忽略文件可使用正则匹配规则，忽略某一类符合正则匹配的文件！！

强制添加被忽略的文件

       •有些时候，你想添加一个文件到 Git，但发现添加不了，原因是这个文件被.gitignore忽略了，
       •强制添加被忽略文件：

git add -f 文件名
1

       •或者你发现，可能是.gitignore写得有问题，需要找出来到底哪个规则写错了，可以用git check-ignore命令检查:

git check-ignore -v 文件名
1

       •还有些时候，当我们编写了规则排除了部分文件时：

       •但是我们发现.这个规则把 .gitignore也排除了，并且App.docx需要被添加到版本库，但是被*.docx规则排除了
       •添加例外规则：这个时候，虽然可以用git add -f强制添加进去，但我们建议你可以添加两条例外规则：

# 不排除.gitignore和App.class:
!.gitignore
!practice.docx
1
2
3

       •把指定文件排除在.gitignore规则外的写法就是**!+文件名**，所以，只需把例外文件添加进去即可

偷懒大法：配置别名

       •除了通过配置忽略文件 来提高git commit 时的便捷性外，Git 中还有一种可以让大家在敲入 Git 命令时偷懒的办法——那就是配置 Git 别名：
       •比如在使用git status命令时，我们可以通过配置别名的方式将其配置为git st，这样在使用时是不是就比输入 git status简单方便很多呢？
       •我们只需要敲一行命令，告诉 Git，以后st就表示status：

git config --global alias.st status
1

       •当然还有别的命令可以简写，很多人都用co表示checkout，ci表示commit，br表示branch等等，你也可以自定义自己喜欢的命令：

git config --global alias.自定义的别名 原命令名称
1

       •注意：- -global参数是全局参数，也就是这些命令在这台电脑的所有 Git 仓库下都可以使用

       •再比如git reset HEAD file命令，他可以把暂存区的修改撤销掉（unstage），重新放回工作区。既然是一个unstage操作，就可以配置一个unstage别名：

git config --global alias.unstage 'reset HEAD'
1

       •当你敲入命令：

git unstage 文件名
1

       •实际上 Git 执行的是：

git reset HEAD 文件名
1

       • 配置 git lg 使得git lg有醒目的颜色：

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
1

配置文件

       •这些自定义的配置文件通常都存放在仓库的 .git/config文件中：

cat .git/config 
1

       •别名就在 [alias] 后面，要删除别名，直接把对应的行删掉即可

       •而当前用户的 Git 配置文件放在用户主目录下的一个隐藏文件.gitconfig中：
       •需要自己在当前电脑用户目录下查找：
       •路径：C:\Users\自己的电脑用户名 （填写自己的，查找自己的配置文件！！）

Git的基础命令

       •在开始 Git 的基础命令学习之前，我们先来认识一下版本库——Repository，接下来我们所有提到的 Git 基础命令，都是基于版本库的。
       •那么什么是版本库呢？版本库又名仓库，英文名 repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”

在已存在目录中初始化仓库 —— git init

       •首先，选择一个合适的地方，创建一个空目录：

mkdir learning-git # 创建目录
cd learning-git # 进入目录
pwd # 显示当前目录
1
2
3

       •第二步，通过git init命令把这个目录变成 Git 可以管理的仓库：

git init
1

       •瞬间 Git 就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），同时在当前目录下多了一个 .git 的目录，这个目录是 Git 来跟踪管理版本库的，如果你没有看到 .git 目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看到了

克隆现有的仓库 —— git clone

       •如果你想获得一份已经存在了的 Git 仓库的拷贝，比如说，你想为某个开源项目贡献自己的一份力，这时就要用到 git clone 命令，Git 克隆的是该 Git 仓库服务器上的几乎所有数据，而不是仅仅复制完成你的工作所需要文件
       •当你执行 git clone 命令的时候，默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来
       •克隆仓库的命令是 git clone
       •使用下述命令可获取Code China中git的帮助文档

git clone https://codechina.csdn.net/codechina/help-docs
1

       •这会在当前目录下创建一个名为 help-docs 的目录，并在这个目录下初始化一个 .git 文件夹， 从远程仓库拉取下所有数据放入 .git 文件夹，然后从中读取最新版本的文件的拷贝。 如果你进入到这个新建的 help-docs 文件夹，你会发现所有的项目文件已经在里面了，准备就绪等待后续的开发和使用
       •自定义本地仓库的名称：
       •当然如果你想在克隆远程仓库的时候，自定义本地仓库的名字也是可以的，你可以通过额外的参数指定新的目录名：

git clone https://codechina.csdn.net/codechina/help-docs Git-help
1

       •这会执行与上一条命令相同的操作，但目标目录名变为了Git-help

       •Git 支持多种数据传输协议。 上面的例子使用的是 https:// 协议，不过你也可以使用 git:// 协议或者使用 SSH 传输协议，比如 user@server:path/to/repo.git

将文件添加到本地仓库中

       •接下来，我们来尝试在已经准备好的 Git 仓库中编辑一个readme.txt文件，内容如下：

但行好事，莫问前程
1

接下来，我们可以通过2个命令将刚创建好的readme.txt添加到Git仓库：

git add命令

       •第一步，用命令git add告诉 Git，把文件添加到仓库：

git add readme.txt
1

       •执行上面的命令，没有任何显示，说明添加成功

git commit命令

       •第二步，用命令git commit告诉 Git，把文件提交到仓库：

git commit -m "a new file"
1

       •git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录
       git commit命令执行成功后会告诉你：
              •1 file changed：1个文件被改动（我们新添加的readme.txt文件）
              •1 insertions：插入了一行内容（readme.txt有一行内容）
       •为什么 Git 添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

git add file1.txt
git add file2.txt file3.txt
git commit -m "add 3 files."
1
2
3

       •完成上述操作，我们已经在本地仓库添加并提交了一个rade.txt文件

       •接下来让我们继续修改readme.txt文件，添加如下内容：

git status命令

       •使用git status命令查看当前文件的状态，在你上次提交之后是否有对文件进行再次修改

git status
1

       •git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改

git diff命令

       •虽然 Git 告诉我们readme.txt被修改了，但并没有告诉我们具体修改的内容是什么，假如刚好是上周修改的，等到周一来班时，已经记不清上次怎么修改的readme.txt，这个时候我们就需要用git diff这个命令查看相较于上一次暂存都修改了些什么内容了

git diff readme.txt
1

       •git diff顾名思义就是查看 difference，显示的格式正是 Unix 通用的 diff 格式，可以从上面的输出看到，我们在第二行添加了“钝鸟先飞，大器晚成”
       •知道了对readme.txt作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件是一样的两步

git add readme.txt
git commit -m "add a sentence"
git status
1
2
3

git log命令

       •作为一个优秀的版本控制系统，Git 能够让我们查看每一次提交的记录。在日常的工作中，我们可以随时对 Git 仓库中的内容进行修改，每当你觉得文件修改到一定程度的时候，就可以“保存一个快照”，这个快照在 Git中 被称为commit / 提交。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失
       •在 Git 中，我们可以通过git log命令查看全部的commit记录：

git log
1

       •git log命令显示从最近到最远的提交日志，我们可以看到2次提交，最近的一次是add a sentence，最早的一次是a new file
       •如果嫌输出信息太多，看得眼花缭乱的，可以试试加上–pretty=oneline参数：

git log --pretty=oneline
1

       •每提交一个新版本，实际上 Git 就会把它们自动串成一条时间线。如果使用可视化工具或者之前在 git 自定义配置中介绍的 git lg命令，就可以更清楚地看到提交历史的时间线：

git lg
1

git reset命令

       •这个时候，假设我们需要将 readme.txt 回退到上一个版本，也就是
a new file的这个版本，我们需要怎么操作呢？
       •首先，Git 必须知道当前版本是哪个版本，在 Git 中，用HEAD表示当前版本，也就是最新的提交d2f7bfb，上一个版本就是HEAD^
       •上上一个版本就是HEAD^^
       •当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100

git reset --hard HEAD^
1

       •现在让我们看看readme.txt的内容是不是版本a new file

cat readme.txt
1

git reflog命令

       •现在，你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？
       •好在 Git 提供了一个命令git reflog用来记录你的每一次命令，当你用git reset --hard HEAD^回退到wrote a readme file版本时，再想恢复到add a sentence，就可以通过git reflog命令找到add a sentence的commit id

git reflog
1

       •从上面的输出可以看到，add a sentence的commit id是d2f7bfb，现在，我们就可以通过 git reset --hard d2f7bfb切换到最新的版本上了

git reset --hard d2f7bfb
1

git commit --amend命令

       •有时候我们提交完了才发现漏掉了几个文件没有添加，或者提交信息写错了。 此时，可以运行带有 –amend 选项的提交命令来重新提交:

git commit --amend
1

       •这个命令会将暂存区中的文件提交。 如果自上次提交以来你还未做任何修改（例如，在上次提交后马上执行了此命令）， 那么快照会保持不变，而你所修改的只是提交信息
       •文本编辑器启动后，可以看到之前的提交信息。 编辑后保存会覆盖原来的提交信息

       •例如，你提交后发现忘记了暂存某些需要的修改，可以像下面这样操作：

git commit -m 'initial commit'
git add forgotten_file
git commit --amend
1
2
3

       •最终你只会有一个提交——第二次提交将代替第一次提交的结果
       •当你在修补最后的提交时，并不是通过用改进后的提交 原位替换 掉旧有提交的方式来修复的， 理解这一点非常重要。从效果上来说，就像是旧有的提交从未存在过一样，它并不会出现在仓库的历史中。
       •修补提交最明显的价值是可以稍微改进你最后的提交，而不会让“啊，忘了添加一个文件”或者 “小修补，修正笔误”这种提交信息弄乱你的仓库历史

git reset HEAD 或 git restore --staged命令

       •接下来我们看看如何操作暂存区和工作目录中已修改的文件。 这些命令在修改文件状态的同时，也会提示如何撤消操作。例如，你已经修改了两个文件并且想要将它们作为两次独立的修改提交， 但是却意外地输入 git add * 暂存了它们两个。如何只取消暂存两个中的一个呢？ git status 命令提示了你：

git add *
git status 
1
2

       •在 “Changes to be committed” 文字正下方，提示使用 git restore --staged < file >…来取消暂存。 所以，我们可以这样来取消暂存 readme.txt 文件，也可以使用**git reset HEAD < file >…**来取消缓存！！

git reset HEAD readme.txt
# 或
git restore --staged readme.txt
1
2
3

       •git reset 确实是个危险的命令，如果加上了 –hard 选项则更是如此。 然而在上述场景中，工作目录中的文件尚未修改，因此相对安全一些

git checkout – file命令

       •如果你并不想保留对 readme.txt 文件的修改怎么办？ 你该如何方便地撤消修改——将它还原成上次提交时的样子（或者刚克隆完的样子，或者刚把它放入工作目录时的样子）？

git checkout -- readme.txt
1

       •请务必记得 git checkout – < file > 是一个危险的命令。 你对那个文件在本地的任何修改都会消失——Git 会用最近提交的版本覆盖掉它。 除非你确实清楚不想要对那个文件的本地修改了，否则请不要使用这个命令！！！

删除操作

       •在 Git 中，删除也是一个修改操作，我们先添加一个新文件test.txt到 Git 并且提交：

git add test.txt

git commit -m "add test.txt"
1
2
3

       •一般情况下，你通常直接在文件管理器中把没用的文件删了，或者使用rm命令删除

rm test.txt
1

       •这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了

       •现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

git rm test.txt
git commit -m 'remove test.txt'
1
2

       •现在，文件就从版本库中被删除了

       •另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

git checkout -- test.txt
1

       •git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原
       •注意：从来没有被添加到版本库就被删除的文件，是无法恢复的！

Git分支管理

       •几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。 在很多版本控制系统中，这是一个略微低效的过程——常常需要完全创建一个源代码目录的副本。对于大项目来说，这样的过程会耗费很多时间
       •有人把 Git 的分支模型称为它的“必杀技特性”，也正因为这一特性，使得 Git 从众多版本控制系统中脱颖而出。 为何 Git 的分支模型如此出众呢？ Git 处理分支的方式可谓是难以置信的轻量，创建新分支这一操作几乎能在瞬间完成，并且在不同分支之间的切换操作也是一样便捷。 与许多其它版本控制系统不同，Git 鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次。 理解和精通这一特性，你便会意识到 Git 是如此的强大而又独特，并且从此真正改变你的开发方式

       •为了真正理解 Git 处理分支的方式，我们需要了解Git是如何保存数据的，前面我们了解到，Git 保存的不是文件的变化或者差异，而是一系列不同时刻的 快照
       •在进行提交操作时，Git 会保存一个提交对象（commit object）。 知道了 Git 保存数据的方式，我们可以很自然的想到——该提交对象会包含一个指向暂存内容快照的指针。 但不仅仅是这样，该提交对象还包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针。 首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象， 而由多个分支合并产生的提交对象有多个父对象

Git分支管理的原理

       •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分支：

创建分支

       •首先，我们创建dev分支，然后切换到dev分支：

git checkout -b dev
1

       •git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

git branch dev
git checkout dev
1
2

       •然后，用git branch命令查看当前分支：

git branch
1

       •git branch命令会列出所有分支，当前分支前面会标一个*号

在新分支上完成工作

       •然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：一年之计在于春，一日之计在于寅

git add readme.txt 
git commit -m "branch test"
1
2

切换分支

       •现在，dev分支的工作完成，我们就可以切换回master分支：

git checkout master
1

       •切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了

       •因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：

合并分支

       •现在，我们把dev分支的工作成果合并到master分支上：
       •git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

git merge dev
1

       •注意到上面的Fast-forward信息，Git 告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快

删除分支

       •合并完成后，就可以放心地删除dev分支了，删除后，查看branch，就只剩下master分支了：

git branch -d dev
git branch
1
2

       •因为创建、合并和删除分支非常快，所以 Git 鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全

创建与切换的新版本命令

       •我们注意到切换分支使用git checkout < branch>，而 Git 中撤销修改则是git checkout – < file>，同一个命令，有两种作用，确实有点令人迷惑
       •实际上，切换分支这个动作，用switch更科学。因此，最新版本的 Git 提供了新的git switch命令来切换分支：
       •创建并切换到新的dev分支，可以使用：

git switch -c dev
1

       •直接切换到已有的master分支，可以使用：

git switch master
1

       •使用新的git switch命令，比git checkout要更容易理解

合并分支的第二种模式

       •通常，合并分支时，如果可能，Git 会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息
       •如果要强制禁用Fast forward模式，Git 就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息，让我们看一看 –no-ff方式的git merge
       •首先，仍然创建并切换dev分支，修改readme.txt文件，并提交一个新的commit：

git switch -c dev
git add readme.txt
git commit -m 'add merge'
1
2
3

       •现在，我们切换回master，并准备合并dev分支，请注意 –no-ff参数，表示禁用Fast forward：

git switch master
git merge --no-ff -m 'merge with no-ff' dev
1
2

       •因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去
       •合并后，我们用git log看看分支历史：

git log
1

       •可以看到，不使用Fast forward模式，merge后就像这样：

       •在实际开发中，我们应该按照几个基本原则进行分支管理：
              •首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活
              •其次，干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，并在master分支发布1.0版本
              •你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了
       •所以，团队合作的分支看起来就像这样:

解决合并请求中的冲突

       •当我们项目越来越大，分支越来越多的时候，在合并分支时，就极有可能出现分支冲突，那我们需要怎么来解决冲突呢？
       •可使用此仓库地址进行练习：https://codechina.csdn.net/qq_45261963/git-learning-course

       •第一步，克隆当前仓库至本地

git clone https://codechina.csdn.net/qq_45261963/git-learning-course
1

       •进入git-learning-course目录，准备新的feature1分支，继续我们的新分支开发，修改readme.txt最后一行，并在feature1分支上提交：

cd git-learning-cours
git switch -c feature1
vim readme.txt
git add readme.txt
git commit -m 'add study'
1
2
3
4
5

git push命令

       •然后使用git push命令将文件推送到远程 origin/feature1 分支：

git push origin feature1
1

       •接下来，让我们切换到master分支，在master分支上修改readme.txt文件，并提交！！！

git switch master
vim README.TXT
git add README.TXT
git commit -m 'add excellent'
1
2
3
4

       •然后使用git push命令将文件 推送到远程 origin/master 分支：

       •现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

       •这种情况下，Git 无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

git merge feature1
1

       •果然冲突了！Git 告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：

git status
1

       •接下来的操作，我们就可以直接在刚才新创建的 合并请求 中来进行操作了

cat README.TXT
1

       •Git 用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们直接在 合并请求 中对文件内容进行修改如下

本地解决冲突

       •如果你是在本地解决的冲突，首先使用git merge --quit停止合并，然后将两个分支的readme.txt修改，提交，合并，在进行推送到远程！！

git merge --quit
1

       •最后，删除feature1分支：

git branch -D feature1
1

Cherry Pick命令

       •对于多分支的代码库，将代码从一个分支转移到另一个分支是常见需求。这时分两种情况。一种情况是，你需要另一个分支的所有代码变动，那么就采用合并git merge。另一种情况是，你只需要部分代码变动（某几个提交），这时可以采用 Cherry pick
       •git cherry-pick命令的作用，就是将指定的提交commit应用于其他分支

git cherry-pick <commitHash>
1

上面命令就会将指定的提交commitHash，应用于当前分支。这会在当前分支产生一个新的提交，当然它们的哈希值会不一样
       •举例来说，代码仓库有master和feature两个分支：

       •现在将提交f应用到master分支：

# 切换到 master 分支
git checkout master

# Cherry pick 操作
git cherry-pick f
1
2
3
4
5

       •上面的操作完成以后，代码库就变成了下面的样子：

       •从上面可以看到，master分支的末尾增加了一个提交f

       •git cherry-pick命令的参数，不一定是提交的哈希值，分支名也是可以的，表示转移该分支的最新提交

git cherry-pick feature
1

       •上面代码表示将feature分支的最近一次提交，转移到当前分支

       •Cherry pick 支持一次转移多个提交``

git cherry-pick <HashA> <HashB>
1

       •上面的命令将 A 和 B 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交

       •如果想要转移一系列的连续提交，可以使用下面的简便语法

git cherry-pick A..B 
1

       •上面的命令可以转移从 A 到 B 的所有提交。它们必须按照正确的顺序放置：提交 A 必须早于提交 B，否则命令将失败，但不会报错

       •注意，使用上面的命令，提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A，可以使用下面的语法：

git cherry-pick A^..B 
1

git cherry-pick命令的常用配置项如下：

-e，–edit

       •打开外部编辑器，编辑提交信息

-n，–no-commit

       •只更新工作区和暂存区，不产生新的提交

-x

       •在提交信息的末尾追加一行cherry picked from commit …，方便以后查到这个提交是如何产生的

-s，–signoff

       •在提交信息的末尾追加一行操作者的签名，表示是谁进行了这个操作

-m parent-number，–mainline parent-number

       •如果原始提交是一个合并节点，来自于两个分支的合并，那么 Cherry pick 默认将失败，因为它不知道应该采用哪个分支的代码变动
       •-m配置项告诉 Git，应该采用哪个分支的变动。它的参数parent-number是一个从1开始的整数，代表原始提交的父分支编号