Git版本控制\远程开发\多人协作
前言
推荐阅读
推荐阅读
推荐阅读
Git 是开源与企业协作开发的必备工具，属于一个程序员的必备技能。本篇Blog将带你走进Git的世界，了解版本控制的相关术语，同时你将学会远程创建自己的仓库并进行维护，掌握团队开发中的Git技巧。
你将学到
- 版本控制的术语及基础知识
- Git的使用
- Git使用与协作规范
版本控制
为什么要强调版本这个概念？如我们在做自己的毕设时，提交给导师看的论文，从最初的v1.pdf，到最后的最终版再也不改再改是狗.pdf，在论文写作的过程中会诞生很多的版本。但如果，最后导师和你商讨，“算了，你还是用最初那个v1.pdf版本吧，你把部分小错误改改就行。”，或许会让你头大，我的latex早改了不知道几版了，最初的版本早丢失了，我还要重新再改回去，天哪！
而针对个人的毕设，改动及版本备份还是非常容易的，若针对多人合作的项目，版本迭代可能会更加复杂，因此，有一款合理高效且开源（免费！）的工具来对自己的项目进行管理是必不可少的。
因此，我们可能会想要一款有如下需求的软件来管理我们的项目，
- 会记录每次对代码的更改（记录，但不要太频繁，只有当我认为需要保存的时候，才保存）
- 记录下Who，When，Why更改相对应的代码。
- 方便任意切换到之前的版本。（例如有菜鸡复写了一段充满bug的代码还自信满满的覆盖掉了原来的屎山代码）
- 方便团队协作（众人拾柴火焰高）
Git和适合上述需求。
版本控制两大主流类型
- 集中式：集中式版本控制将版本库与工作空间分离，用户计算机上只保存当前要处理的项目，而版本库只存在于中央仓库里。优点：绝对的控制权。缺点：有权限的人删库跑路
2.分布式：分布式版本控制中，无论是用户主机还是远程仓库主机，都是一个完整的版本控制系统。优点：每个人都有一份完整的代码，避免有人删库跑路。同时提交次数减少（在自己本地仓库调试成功再提交到远程仓库），更加高效。缺点：缺少绝对的控制权。（也不算缺点吧，独裁者的下场大家太熟悉了。）
而Git就是分布式系统。
专业术语
来自于：版本控制 GitChat 课
| 术语 | 作用 |
|---|---|
| 提交 | Git 将数据看做文件系统的一组快照。每次 commit（提交），它都对文件当时的状况拍照，并存储对该快照的引用。你可以将其看做游戏中的保存点，它会保存项目的文件和文件操作信息。你在 Git 中的所有操作最终都会 commit，因此 commit 是 Git 中的基本单位。 |
| 仓库 | 仓库（Repository）是一个包含项目内容的目录。仓库可以存储在本地，或存储在远程计算机上。也叫Git仓库。 |
| 工作目录 | 工作目录（Working Directory）是你在计算机的文件系统中看到的文件。当你在代码编辑器中打开项目文件时，你是在工作目录中处理文件。工作目录与仓库内容分离，工作目录中只能取仓库某一commit对其更改。 |
| 暂存区 | Git 目录下的一个文件，存储的是即将进入下个 commit 内容的信息。可以将暂存区（Staging Index）看做准备工作台，Git 将在此区域获取下个 commit。暂存区中的文件是准备添加到仓库中的文件。 |
| 版本库 | Git 仓库文件夹中有一个隐藏目录 .git ， 里面记录了commit历史。 |
| 检出 | 检出（Checkout）是指将版本库中某个commit的内容复制到工作目录下。 |
| SHA | SHA 是全称是”Secure Hash Algorithm”（安全哈希算法），用来标记每个 commit 的 ID 编号。SHA根据 Git 中的文件或目录结构的内容计算得出，不会重复。 注：Git仓库中为每次提交都创建了 Id，也就是 SHA 。他们看起来类似这样 e2adf8ae3e. |
| 分支 | 分支（Branch）是从主开发流程中分支出来的新的开发流程。可以用于软件分支如高端、中端、低端版本，或开发版、测试版、生产版等。你也可以将分支当作做游戏中的保存点，开辟新分支进行有风险的尝试。如果尝试不奏效，则回到保存的位置。 |
如上图中，存在两个仓库,Remote远程仓库和Repository本地仓库；workspace是我们的工作目录；index是暂存区
Git的使用
如果你对相关术语有一个基本的概念，那么接下来将按照顺序步骤讲解一下Git的使用流程。本教程不再讲解如何安装Git，如果有任何Git指令上的疑问，建议使用git help。
基本配置
# 设置你的 Git 用户名
git config --global user.name "yannqi"
# 设置你的 Git 邮箱
git config --global user.email yannqi@qq.com
# 确保 Git 输出带有颜色
git config --global color.ui auto?
- 配置级别
–local（默认，高级优先）：只影响本地仓库
–global(中优先级)：只影响所有当前用户的git仓库
–system（低优先级）：影响到全系统的git仓库
注：基本配置这一步很重要，因为需要知道是谁更改的代码。
创建自己的仓库：init/clone仓库，
创建你自己的repository有两种方法，从零开始or克隆他人的仓库。
注：建议你从github或gitee(推荐国产产品)上fork或者新建一个仓库，然后clone到本地。
方法一：
#初始化仓库
git init
方法二： [url]来自于github/gitee
#克隆remote仓库到本地
git clone [url]
方法三：（很少用）
#把一个已有的本地仓库与远程仓库关联
git remote add origin [url]
origin为远程仓库的别名，默认origin
我们可以使用 git remote -v 查看关联的仓库。
本地代码与云端仓库实现同步
代码从工作区到云端仓库，需要经历三个过程
git add #添加工作目录中的文件到暂存区
git commit #将暂存区内的文件保存到仓库
git push #将本地仓库文件推送到云端仓库
工作区到暂存区
将代码提交到仓库的第一步是需要先将写好的代码提交到暂存区。
git add [文件名] 或 git add .。这个 .代表当前目录下所有文件，很省事。
注：如何删除错误跟踪的文件：
如果我们git add [文件名]，跟踪了一个错误的文件，想要把它从暂存区拿出来，使用git rm --cached [文件名]。
注：如何避免跟踪所有文件：
git add .会包含当前目录下的所有文件，但我们项目中不只有代码文档，还有很庞大的数据集，条件不允许放到暂存区。因此，我们需要在本地仓库中新建一个.gitignore文件夹，里面将我们不需要上传到远程仓库的文件或文件夹给忽略掉。.gitignore内语法如下：
# - 注释
? - 匹配一个字符
* - 匹配0到多个字符
[abc] - 匹配 a、b 或 c
** - 匹配嵌套目录- a/**/d
a/d
a/b/d
a/b/c/d
一个.gitignore的示例如下：
# Build and Release Folders
bin-debug/
bin-release/
[Oo]bj/
[Bb]in/
# Other files and folders
.settings/
# Executables
*.swf
*.air
*.ipa
*.apk
# Project files, i.e. `.project`, `.actionScriptProperties` and `.flexProperties`
# should NOT be excluded as they contain compiler settings and other important
# information for Eclipse / Flash Builder.
暂存区到本地仓库
现在我们已经将新建的代码文件添加到了暂存区（index），我们可以将暂存内容提交到本地仓库，实现一个版本快照。
实现方式：git commit -m '注释信息'。-m '注释'可添加可不添加，多人协作建议添加，方便他人阅读。
也可以采用两个 -m 参数的方式添加简短描述与正文，git commit -m '注释信息' -m '详细描述,字符可以长点，但是注释信息尽量简短为好，只描述实现了什么功能，或做了什么改动'
本地仓库到云端仓库
git push，即可将本地仓库推到云端仓库。
git push <远程仓库简称> <要推送的分支>
例如：我们已经添加了 Git 的远程仓库别名为 origin。我们想推送 master 分支，命令为：
git push origin master
云端仓库同步到本地仓库
在团队协作时，云端仓库代码往往会有别人参与修改，因此我们需要每次码代码前，将远程仓库的项目拉取到本地仓库。
例如我们想将远程仓库 origin 上的 master 分支拉取到本地，运行以下命令：
#谨慎使用，会覆盖掉你本地仓库的代码，如果你正在编辑的代码没有上传到云端，回呗覆盖掉。
git pull origin master
但是实际开发中，远程仓库有版本变更，本地仓库也有版本变更，此时远程与本地都有新的 commit 提交，此时我们可以使用 git fetch 命令。
git fetch origin master
之后再
git merge origin/master
注：pull和fetch的区别：
pull = fetch + merge
- git pull
- git fetch origin master
注意：origin/master 和 不同颜色的master
- git merge origin/master
注意：origin/master 和 不同颜色的master
4.git push origin master
注意：origin/master 和 不同颜色的master
常用Git指令
查看仓库的状态
#跟踪状态 用于查看在你上次提交之后是否有对文件进行再次修改。
git status
#简短输出
git status -s
#输出结果A：表示有文件修改 AM：指这个文件在我们将它添加到暂存区（index）之后又有改动。
通过查看仓库的状态，可以得到当前我们所处的Branch（分支），index（暂存区）内有没有亟待commit(提交)的代码。
这一步非常重要，建议经常使用。
查看历史记录
#查看本地仓库的提交历史
git log
#查看简短的历史提交
git log --oneline
#详细查看更改了哪些文件
git log --stat
#查看某次提交的详细信息 ，可以跟SHA 简写（大于4个字符）
git show SHA
#查看每个人的 commit 记录
git shortlog
#查看某个人的提交记录
git log --author="name"
#查看已经add但仍未commit的修改
git diff
代码版本回退
慎用！会删除掉当下版本？建议做好备份。
#回退到上一次 commit 的状态
git reset --hard HEAD
#回退到任意版本
git reset --hard SHA
#将某个历史版本替换到工作区
git checkout SHA
Git团队协作使用规范
给代码打标签[Tag]
当我们软件开发到一定程度，具备一定功能时，已经成为一个可发布的版本，我们会为它添加系统版本号。
版本号规则
<主版本号>.<次版本号>.<修订版本号>.<日期版本号加希腊字母版本号>
希腊字母版本号共有 5 种：base、alpha、beta、RC、release。
例如：：1.1.1.200512_beta
软件版本阶段说明：
- base 版: 最最基础，软件功能完善过程，程序员内部开发使用。？
- Alpha 版：以实现软件功能为主，Bug 较多，内部交流使用，需要继续修改。
- Beta 版：消除了严重错误，但存在缺陷，需要继续测试。
- RC 版：该版本已经相当成熟，基本上不存在 Bug，与即将发行的正式版相差无几。
- Release 版：交付用户使用的版本，该版本有时也称为标准版。
版本号修改规则（1.1.1.200512_beta）：
- 主版本号（1）：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。
- 子版本号（1）：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。
- 阶段版本号（1）：一般是 Bug 修复或是一些小的变动，常修复 Bug 发布修订版。
- 日期版本号（200512）：记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。
- 希腊字母版本号（beta）：用于标注当前版本的软件处于哪个开发阶段，进入到另一个阶段时需要修改此版本号。
Git添加版本号
git tag -a [版本号] SHA #为当前 commit 创建版本
#向最近的 commit 添加标签，如果提供了 SHA，则向具体的 commit 添加标签
git show [版本号] #查看版本
git tag -d [版本号] #删除版本
例如：
git tag -a v1.1.0 a1d2fa #为当前 commit 创建版本
#向最近的 commit 添加标签，如果提供了 SHA，则向具体的 commit 添加标签
git show v1.1.1.200512_beta #查看版本
git tag -d v1.1.1.200512_beta #删除版本
合理利用分支
在团队开发中，团队各成员都有自己的任务，当软件出现 Bug 或开发新功能时，为了不影响当前的开发流程，会创建一个新的分支用于 Bug 修复或新功能开发，当任务完成后再合并到主开发流程（master 分支）。
创建与删除分支
例如，我们创建一个dev分支，用于新功能的开发。
git branch dev
如果，想给之前的commit创建分支，则需要加上对应的SHA，
git branch dev 4e5f
同时，删除分支一样，
git branch -d [分支名]
切换分支/合并分支
如果我们现在进行 commit 的话，该 commit 将添加到 master 分支，而不是 dev分支。要在分支之间进行切换，我们需要使用 git 的 checkout 命令，也就是将 HEAD 指针指向 dev分支。
git checkout dev
如图所示，首先切换到dev分支，HEAD指针指向dev，然后commit一个文档。之后切换到master分支，又commit了一个新的文档。
如上图，此时有两个分支，如何将分支进行合并，合并 dev 分支前，你必须位于 master 分支。
# 查看当前所在分支，确保自己位于 master 分支
git branch
# 切换到 master 分支
git checkout master
# 执行合并
git merge dev
发生合并时，Git 将更改的代码行合并到一起，提交一个 commit 来记录合并操作。
因为我们合并的内容有冲突，Git 会在编辑器显示冲突的代码，由我们决定保留哪些代码。
合并冲突提示：注意 <<< ||| ==>>> 符号
编辑器中的字符：
- <<< 到 ||| 显示的是当前 master 分支上修改后的内容
- ||| 到 ---- 向您显示 master 分支与 dev 分支修改前共同的内容是什么
- — 到 >>> 显示的是 dev 分支上修改后的内容，也就是要合并分支的内容
我们根据需要删除无用的代码，然后将修改添加到暂存区，并进行提交更改。
解决冲突，保留最终代码
提交完成后，你可以采用如下命令查看当前分支情况（去掉 --all 不显示 Tag）：
git log --oneline --decorate --graph --all
如何利用git为github上开源代码做出贡献
笔者还没尝试过，之后试了更新。
