来都来了，你确定不看看，Git从零开始的详细使用教程，你一定能学废（图文并茂版）

admin管理员组

文章数量:1566220

Git详细使用教程！！！

• • 认识Git
  • Windows安装Git
  • Git环境配置
  • • 用户名与邮箱地址的设置
    • Git中实用的自定义配置
    • • Git忽略某个或某类文件
      • 强制添加被忽略的文件
  • 偷懒大法：配置别名
  • 配置文件
  • Git的基础命令
  • • 在已存在目录中初始化仓库 —— git init
    • 克隆现有的仓库 —— git clone
    • 将文件添加到本地仓库中
    • • git add命令
      • git commit命令
      • git status命令
      • git diff命令
      • git log命令
      • git reset命令
      • git reflog命令
      • git commit --amend命令
      • git reset HEAD 或 git restore --staged命令
      • git checkout -- file命令
      • 删除操作
  • Git分支管理
  • • Git分支管理的原理
    • 创建分支
    • 在新分支上完成工作
    • 切换分支
    • 合并分支
    • 删除分支
    • 创建与切换的新版本命令
    • 合并分支的第二种模式
  • 解决合并请求中的冲突
  • • git push命令
    • 本地解决冲突
  • Cherry Pick命令
  • • git cherry-pick命令的常用配置项如下：
    • • -e，--edit
      • -n，--no-commit
      • -x
      • -s，--signoff
      • -m parent-number，--mainline parent-number

认识Git

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

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

Windows安装Git

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

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

choco install git.install

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 # 填写自己的邮箱地址

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

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

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

git config user.name
git config user.email

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

git config --list

Git中实用的自定义配置

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

git config --global color.ui true

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 文件名

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

git check-ignore -v 文件名

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

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

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

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

偷懒大法：配置别名

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

git config --global alias.st status

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

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

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

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

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

       •当你敲入命令：

git unstage 文件名

       •实际上 Git 执行的是：

git reset HEAD 文件名

       • 配置 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"

配置文件

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

cat .git/config 

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

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

Git的基础命令

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

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

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

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

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

git init

       •瞬间 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/codechina/help-docs

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

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

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

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

将文件添加到本地仓库中

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

但行好事，莫问前程

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

git add命令

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

git add readme.txt

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

git commit命令

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

git commit -m "a new file"

       •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."

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

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

git status命令

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

git status

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

git diff命令

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

git diff readme.txt

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

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

git log命令

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

git log

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

git log --pretty=oneline

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

git lg

git reset命令

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

git reset --hard HEAD^

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

cat readme.txt

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

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

git reset --hard d2f7bfb

git commit --amend命令

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

git commit --amend

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

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

git commit -m 'initial commit'
git add forgotten_file
git commit --amend

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

git reset HEAD 或 git restore --staged命令

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

git add *
git status 

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

git reset HEAD readme.txt
# 或
git restore --staged readme.txt

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

git checkout – file命令

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

git checkout -- readme.txt

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

删除操作

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

git add test.txt

git commit -m "add test.txt"

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

rm test.txt

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

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

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

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

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

git checkout -- test.txt

       •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

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

git branch dev
git checkout dev

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

git branch

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

在新分支上完成工作

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

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

切换分支

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

git checkout master

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

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

合并分支

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

git merge dev

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

删除分支

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

git branch -d dev
git branch

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

创建与切换的新版本命令

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

git switch -c dev

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

git switch master

       •使用新的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'

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

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

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

git log

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

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

解决合并请求中的冲突

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

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

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

       •进入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'

git push命令

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

git push origin feature1

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

git switch master
vim README.TXT
git add README.TXT
git commit -m 'add excellent'

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

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

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

git merge feature1

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

git status

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

cat README.TXT

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

本地解决冲突

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

git merge --quit

       •最后，删除feature1分支：

git branch -D feature1

Cherry Pick命令

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

git cherry-pick <commitHash>

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

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

# 切换到 master 分支
git checkout master

# Cherry pick 操作
git cherry-pick f

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

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

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

git cherry-pick feature

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

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

git cherry-pick <HashA> <HashB>

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

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

git cherry-pick A..B 

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

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

git cherry-pick A^..B 

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开始的整数，代表原始提交的父分支编号

本文标签： 来了图文并茂一定能从零开始教程