标签：部分 输入 命令行 pretty 高效 clone 阶段 分支合并 物理
本文由 简悦 SimpRead 转码， 原文地址 mp.weixin.qq.com
版本控制系统概述
场景一：代码备份
场景二：代码还原【版本控制】
场景三：协同开发
场景四：追溯问题代码
版本控制系统能追踪项目，从开始到结束的整个过程。对编程人员而言，版本控制技术是团队协作开发的桥梁，助力于多人协作同步进行大型项目开发。
软件版本控制系统的核心任务：查阅项目历史操作记录、实现协同开发。
常见的两种版本控制类型
集中式版本控制工具：集中式版本控制工具，版本仓库是集中存放在中央服务器的，team 里每个人工作时，从中央服务器下载代码。每个人修改后，提交到中央版本仓库。提交（commit）代码需要联网。如 SVN。
分布式版本控制工具：分布式版本控制系统可以没有 “中央服务器”，每个人的电脑上都是一个完整的版本仓库，这样工作的时候，不需要联网。因为版本仓库就在你自己的电脑上。多人协作只需要各自修改，开发完成即可，推送给对方，推送的时候是联网将整个版本仓库推过去。如 GIT。
Git 是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目的版本管理。
速度、简单的设计
对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
完全分布式
有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）
Clone：克隆，从远程仓库中克隆代码到本地仓库，第一次操作
Push：推送，代码完成后，需要和团队成员共享代码时，将代码推送到远程仓库
Pull：拉取，从远程库拉代码到本地库，自动进行合并（merge），最后放到工作区
checkout：将本地仓库的内容检出到工作区
add：在提交前先将代码提交到暂存区
commit：提交到本地仓库
本地仓库：在本地主机上的一个代码库，可以独立存在，也可以与远程仓库进行关联
工作区：对任何文件的修订（增删改），都先放在工作区，工作区不与任何仓库分支进行关联
暂存区：把修订的文件，从工作区经过 add（添加）后与某一个仓库分支进行关联，只有进入暂存区的文件才能 commit（提交）到本地仓库。
远程仓库：在局域网或互联网上的一个主机，存放代码库的主机或平台，比如 GitHub、Gitee
分支：代码存放在仓库，默认是主分支（master），可以在主分支基础上创建很多子分支，比如 develop、BugFix 等。
一个文件夹包含 .git 隐藏目录（Git 工作目录），说明此文件目录使用 Git 版本管理。
.git 隐藏目录中存储了很多配置信息、日志信息和文件版本信息、暂存区信息等。.git 文件夹中有很多文件，其中有一个 index 文件就是暂存区，也可以叫做 stage。暂存区是一个临时保存修改文件的地方。
Git 是分布式的版本控制系统。
Git 解决的问题：代码备份、还原；协同开发；多版本同时开发、追溯问题代码。
本地仓库：存储所有版本代码
工作区：编辑代码区
暂存区：准备提交的代码都放这里
远程仓库：用于团队之间共享代码
分支：多个版本同时开发，master 主分支，develop 开发分支，test 测试分支
远程仓库操作：
clone 克隆：第一次从远程仓库下载代码
pull 拉取：获取团队其他成员代码提交变动
push 推送：完成后的代码上传到远程仓库
本地仓库操作：
checkout 检出：将本地仓库的内容检出到工作区add 添加：向暂存区添加代码，准备提交
commit 提交：把暂存区的代码提交到本地仓库
下载地址：https://git-scm.com/download
Git GUI：Git 提供的图形界面工具
Git Bash：Git 提供的命令行工具
进行全局设置，如用户名、邮箱：
# 设置全局用户名
git config --global user.name "YOUR_NAME"
# 设置邮箱
git config --global user.email "YOUR_EMAIL"
通过上面的命令设置的信息会保存在 .gitconfig 文件中
其中， --global 指定为全局配置，不使用该参数，则为当前所在仓库配置。
以上配置信息默认存储在用户目录下，如果设置错误，可以删除 .gitconfig 文件，重新操作以上命令即可。
查看配置信息：
# 查看配置信息
git config --list
要使用 Git 对代码进行版本控制，首先需要构建本地仓库
通常有两种方式：
在本地初始化一个 Git 仓库
从远程仓库克隆一个仓库（远程仓库演示）
1）在电脑的任意位置创建一个空目录（例如 local_repo1）作为本地 Git 仓库
2）进入这个目录中，点击右键打开 Git bash 窗口
3）执行命令 Git init 如果在当前目录中看到 .git 文件夹（此文件夹为隐藏文件夹）则说明 Git 仓库创建成功
在本地创建 Git 版本库，需要使用 git init 命令。
新建一个存放版本库的目录，进入到该目录所在路径，然后执行：
git init
查看目录结构中，就可以看到包含有 .git 子目录，这就说明创建版本库成功了
# 命令形式：
git status
# 更简洁的信息命令形式：
git status -s
要将一个文件纳入到版本库管理，首先要将其添加到暂存区，然后才能提交到仓库中。
将文件添加到暂存区，使用的是 git add：
# 添加单个文件到暂存区
git add Readme.txt
# 将当前目录下所有修改添加到暂存区，除按照规则忽略的之外
git add .
注意：空文件夹是不会被添加到暂存区中的。
将暂存区中的文件，提交到仓库中。需要使用 git commit：
# 如果暂存区有文件，则将其中的文件提交到仓库
git commit
# 带评论提交，用于说明提交内容、变更、作用等
git commit -m ‘YOUR_COMMENTS‘
注意：直接用 git commit 提交会弹出添加评论的页面。
需要查看自己做过哪些提交，来回顾自己完成的部分；或者需要寻找某个具体的提交来查看当时的代码：
# 显示所有提交的历史记录
git log
# 单行显示提交历史记录的内容
git log --pretty=oneline
在 git log 的输出内容中，可以看到每次提交的 ID 是一个 40 位的字符串。
有了 git log 来查看提交的历史记录，就可以通过 git reset --hard 来回退到需要的特定版本，然后使用当时的代码进行各种操作。
# 回退到 commit_id 指定的提交版本
git reset --hard ‘COMMIT_ID‘
当退回到某个提交的版本以后，再通过 git log 是无法显示在这之后的提交信息的。但是，通过 git reflog 可以获取到操作命令的历史。
因此，想要回到未来的某个提交，先通过 git reflog 从历史命令中找到想要回到的提交版本的 ID，然后通过 git reset --hard 来切换。
git reflog
git reset --hard ‘COMMIT_ID‘
在文件未添加到暂存区之前，对想删除文件可以直接物理删除。如果文件已经被提交，则需要 git rm 来删除：
# 删除已经被提交过的 Readme.md
git rm Readme.md
注意：git rm 只能删除已经提交到版本库中的文件，其他状态的文件直接用这个命令操作是出错的。
一般在工作区中，并不是所有文件都需要纳入版本控制的
这种不需要进行版本控制的通常都是些自动生成的文件。比如：IDEA 工程文件（springmvc.iml）、编译后文件 target、系统上传的图片 img。
在这种情况下可以在工作目录中创建一个名为 .gitignore 的文件（文件名称固定），列出要忽略的文件。
一般在工程初始化时，提前准备好需要忽略的文件列表。
几乎所有的版本控制系统都以某种形式支持分支。使用分支意味着可以把工作从开发主线上分离开来进行重大的 Bug 修改、开发新的功能，以免影响开发主线。
在开发中，一般有如下分支使用原则与流程
master 生产分支：线上分支，主分支，中小规模项目作为线上运行的应用对应的分支。
test 测试分支：从 master 创建的分支，一般作为测试部门的测试分支，进行预发测试；测试完成后，需要合并到 master 分支，进行上线，中小规模项目可省略此分支。
develop 开发分支：从 test 创建分支，如果开发没有 test 分支，是从 master 创建的分支，一般作为开发部门的主要开发分支；如果没有其他并行开发不同期上线要求，都可以在此版本进行开发；阶段开发完成后，需要是合并到 test 分支继续测试，如果没有 test 分支，可直接合并到 master 分支。
hotfix(bugfix) 分支：从 master 派生的分支，一般作为线上 bug 修复使用，修复完成后需要合并到 master、test、develop 分支。
查看分支使用 git branch：
# 查看本地分支信息
git branch
# 查看相对详细的本地分支信息
git branch -v
# 查看包括远程仓库在内的分支信息
git branch -av
注意：在 git branch 的输出内容中，有一个分支前面带有 * 号，这标识当前所在的分支
当要修复一个 Bug 或者开发一个新特性，甚至是怕打乱原来的代码，都可以新建一个分支来避免对原来代码的影响。
# 新建一个名称为 dev 的分支
git branch dev
当创建完分支以后，需要切换到新建的分支，否则，所有的修改，还是在原来的分支上。所有的改动，只能影响到当前所在的分支。
# 新建完 dev 分支以后，通过该命令切换到 dev 分支
git checkout dev
# 新建 dev 分支，并切换到该分支上
git checkout -b dev
这个命令合并了前两个独立的命令，平常使用中一般这样使用。
当修复完成一个 Bug，或者开发完成一个新特性，就会把相关的 Bug 或者特性的上修改合并回原来的主分支上，这时候就需要 git merge 来做分支的合并。
首先需要切换回最终要合并到的分支，如 master：
# 切换回 master 分支
git checkout master
# 将 dev 分钟中的修改合并回 master 分支
git merge dev
合并回主分支的时候，可能会面临到冲突的问题 git add ./
当之前创建的分支，完成了它的使命，如 Bug 修复完，分支合并以后，这个分支就不在需要了，就可以删除它。
# 删除 dev 分支
git branch -d dev
现在已经在本地创建了一个 Git 仓库，又想让其他人来协作开发，此时就可以把本地仓库同步到远程仓库，同时还增加了本地仓库的一个备份。
那么如何搭建 Git 远程仓库呢？可以借助互联网上提供的一些代码托管服务平台来实现，其中比较常用的有 GitHub、码云等。
GitHub（https://github.com/）是一个面向开源及私有软件项目的托管平台，因为只支持 Git 作为唯一的版本仓库格式进行托管，故名 GitHub。
码云（https://gitee.com/ ）是国内的一个代码托管平台，由于服务器在国内，所以相比于 GitHub，码云速度会更快。
第一步：登录网址，点击 sign up 注册账号
第二步：填写信息，注意邮箱要真实有效
第三步：直接点击 join a free plan
第四步：直接划到最下面点击 complete setup
第五步：邮箱需要验证，验证完成后登陆进 GitHub
验证邮箱：进入邮箱后点击按钮，进行页面跳转
跳转页面后：点击 skip this for now
第六步：登录
点击 create repository 按钮仓库就创建成功了。
GitHub 支持两种同步方式 https 和 ssh。如果使用 https 很简单基本不需要配置就可以使用，但是每次提交代码和下载代码时都需要输入用户名和密码。而且如果是公司配置的私有 Git 服务器一般不提供 https 方式访问，所以要来着重演示 ssh 方式。
SSH - Secure Shell 的简写形式。通过使用 SSH，可以把所有传输的数据进行加密，这样 "中间人" 这种攻击方式就不可能实现了，而且也能够防止 DNS 欺骗和 IP 欺骗。使用 SSH，还有一个额外的好处就是传输的数据是经过压缩的，所以可以加快传输的速度。
注：使用 SSH 同步方式需要先生成密钥并在 GitHub 配置公钥
在 windows 下我们可以使用 Git 的 Bash.exe 来生成密钥，右键菜单打开 Git Bash
git bash 执行命令生成公钥和私钥：
ssh-keygen -t rsa
执行命令完成后，在 window 本地用户 .ssh 目录 C:\Users\用户名.ssh 下面生成如下名称的私钥文件和公钥文件：
id_rsa
id_rsa.pub
密钥生成后需要在 GitHub 上配置密钥，本地才可以顺利访问。
在 key 部分将 id_rsa.pub 文件内容添加进去，然后点击 Add SSH key 按钮完成配置。
如果想查看已经配置的远程仓库服务器，可以运行 git remote 命令。它会列出指定的每一个远程服务器的简写。如果已经克隆了远程仓库，那么至少应该能看到 origin ，这是 Git 克隆的仓库服务器的默认名字。
# 命令形式：
git remote -v
# origin ——仓库服务器的默认名称
如果已经有了一个本地仓库，然后打算将它发布到远程，供其他人协作。那么使用：
# 为本地仓库添加远程仓库
git remote add origin your_remote_git_repo
当本地仓库中，代码完成提交，就需要将代码等推送到远程仓库，这样其他协作人员可以从远程仓库同步内容。
# 第一次推送时使用，可以简化后面的推送或者拉取命令使用
git push -u origin master
# 将本地 master 分支推送到 origin 远程分支
git push origin master
注意：
git push -u origin master，第一次使用时，带上 -u 参数，在将本地的 master 分支推送到远程新的 master 分支的同时，还会把本地的 master 分支和远程的 master 分支关联起来。
推送之前，需要先 pull 远端仓库，如果发现提交版本不一致，会出现错误
在多人协作过程中，当自己完成了本地仓库中的提交，想要向远程仓库推送前，需要先获取到远程仓库的最新内容。
可以通过 git fetch 和 git pull 来获取远程仓库的内容。
git fetch origin master
git pull origin master
git fetch 和 git pull 之间的区别：
git fetch 是仅仅获取远程仓库的更新内容，并不会自动做合并。
git pull 在获取远程仓库的内容后，会自动做合并，可以看成 git fetch 之后 git merge。
如果因为一些原因想要移除一个远程仓库
# 命令形式
git remote rm <shortname>
注意：此命令只是从本地移除远程仓库的记录，并不会真正影响到远程仓库
如果想获得一份已经存在了的 Git 仓库的拷贝，这时就要用到 git clone 命令。Git 克隆的是该 Git 仓库服务器上的几乎所有数据（包括日志信息、历史记录等），而不仅仅是复制工作所需要的文件。当执行 git clone 命令的时候，默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。
如果本地没有仓库，希望从已有的远程仓库上复制一份代码，那么就需要 git clone。
# 通过 https 协议，克隆 Github 上 git 仓库的源码
git clone https://github.com/lagou-zimu/repo1.git
# 通过 ssh 协议，克隆 Github 上 git 仓库的源码
git clone git@github.com:lagou-zimu/repo1.git
注意：git clone 后面的仓库地址，可以支持多种协议，如 https，ssh 等。
拉取 pull
# 命令形式
git pull [远程仓库名称] [分支名称]
在一段时间，A、B 用户修改了同一个文件，且修改了同一行位置的代码，此时会发生合并冲突。
A 用户在本地修改代码后优先推送到远程仓库，此时 B 用户在本地修订代码，提交到本地仓库后，也需要推送到远程仓库，此时 B 用户晚于 A 用户推送，故需要先拉取远程仓库代码，经过合并后才能推送代码。在 B 用户拉取代码时，因为 A、B 用户同一段时间修改了同一个文件的相同位置代码，故会发生合并冲突。
A 用户：修改 a.java 代码推送到远程仓库
B 用户：修改 a.java 同一行代码，提交之后，合并码出现冲突
解决方法：
1. 先拉取代码
2. 然后打开代码解决冲突
3. 再提交
远程仓库操作常用命令：
# 查看所有远程仓库名称
git remote
# 查看远程仓库缩略信息
git remote -v
# 将本地仓库代码推送到远程仓库
git push origin master
# 克隆远程仓库代码到本地
git clone https://github.com/lagou-zimu/repo1.git
# 拉取远程仓库代码到本地（fetch+merge）
git pull origin master
安装好 IntelliJ IDEA 后，如果 Git 安装在默认路径下，那么 idea 会自动找到 Git 的位置，如果更改了 Git 的安装位置则需要手动配置下 Git 的路径。选择 File → Settings 打开设置窗口，找到Version Control 下的 Git 选项，输入 git.exe 的路径，点击 Test 按钮，现在执行成功，配置完成。
执行步骤：
在 GitHub / 码云中创建远程仓库
将 maven 工程交给 Git 管理
配置忽略文件
提交到本地仓库
推送到远程仓库
启动 IDEA，从远程仓库克隆项目
操作步骤：
推送前一定要先拉取远程仓库对应分支
如果有冲突，先解决冲突，并提交到本地仓库
推送当前分支到远程仓库
操作步骤：
创建分支
切换分支执行操作
执行合并操作，master 合并 dev，并推送到远程仓库
对代码修改后，可以点击 Show History 按钮，对比差异
标签：部分 输入 命令行 pretty 高效 clone 阶段 分支合并 物理
原文地址：https://www.cnblogs.com/wuchaoxin/p/14554022.html
