来都来了,你确定不看看,Git从零开始的详细使用教程,你一定能学废!!(万字长文图文并茂版!!!!)
Posted 温柔且上进c
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了来都来了,你确定不看看,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
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 # 填写自己的邮箱地址
•再次强调,如果使用了 –global 选项,那么该命令只需要运行一次,因为之后无论你在该系统上做任何事情, Git 都会使用这些信息
•当你想针对特定项目使用不同的用户名称与邮件地址时,可以在那个项目目录下运行没有 –global 选项的命令来配置:
•特定的项目目录下使用下述命令:
git config user.name "ycx" #引号中是你需要使用的用户名
git config user.email xxx.qq.com # 填写自己的邮箱地址
•可以通过输入 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.net/codechina/help-docs
•这会在当前目录下创建一个名为 help-docs 的目录,并在这个目录下初始化一个 .git 文件夹, 从远程仓库拉取下所有数据放入 .git 文件夹,然后从中读取最新版本的文件的拷贝。 如果你进入到这个新建的 help-docs 文件夹,你会发现所有的项目文件已经在里面了,准备就绪等待后续的开发和使用
•自定义本地仓库的名称:
•当然如果你想在克隆远程仓库的时候,自定义本地仓库的名字也是可以的,你可以通过额外的参数指定新的目录名:
git clone https://codechina.csdn.net/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.net/qq_45261963/git-learning-course
•第一步,克隆当前仓库至本地
git clone https://codechina.csdn.net/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从零开始的详细使用教程,你一定能学废!!(万字长文图文并茂版!!!!)的主要内容,如果未能解决你的问题,请参考以下文章
来都来了,你确定不看看常用的冒泡排序算法< 一 >!(python版本 图文并茂!!!!)
来都来了,你确定不看看,阿里云Centos8安装Docker!!(图文并茂版!!!)
来都来了,你确定不看看常用的选择排序算法< 二 >!(python版本 图文并茂!!!!)
来都来了,你确定不看看,使用python中的科学计算库Numpy操作数组,你一定能学废!!(图文并茂版!!!!)