Git使用指南-基础

本文介绍git基本概念，从典型场景出发介绍如何使用git，帮助快速上手，达到项目版本控制的目的。git是一个版本控制软件，主要目的是帮助用户管理文件版本，包括更新版本，回退版本，辅助多人协作同时修改同一个文件等等。

git常用语软件开发，但绝对不仅可以用在这个方面，任何需要做版本控制的地方都有git的用武之地。

一个场景

想想以下下面的场景，就会明白git的作用和必要性。

假设作家要写一本小说，首先会写出一个大概的提纲，保存为提纲.txt，作家针对这个提纲会进行后续操作，那么针对如何保存这个文件，有如下几个方案。

方案一：

直接保存一份文件，就是提纲.txt，如果作家对这个提纲不满意，可以直接在上面修改，直接保存。

问题在于很多情况下，你会发现改动后还没有原来的好，此时需要回到之前的版本，但是由于只保存了一份，这里无法满足这个需求，只能手动一点点改回去，十分不方便。

由此提出方案二

方案二：

每次完成后保存成一个文件，并带上后缀，后续修改基于先前的文件，但是需要创建新的文件。

比如，初次完成保存为提纲V1.txt，后续要改则创建提纲V2.txt然后将v1中的内容粘贴过来，更改。

方案二解决了方案一里无法回滚的问题，如果觉得之前某个版本好都可以很快找回。但也存在问题，主要是两个方面：

1. 浪费存储空间，一个文件存在多个版本
2. 无法多人协作，假设作家希望其他人提供思路，那就存在编辑问题，是否大家都基于最新版本来修改？如果是，如何解决冲突问题，即作家更新上去的内容被其他人抹掉等
   由此提出第三个方案

方案三：

专门用文件来记录目标文件的变更，将这个称作变更日志，比如v2比v1结尾处多了3行等等。这样就可以根据这个变更日志来回退文件。同时节省了存储空间。

对于多人协作修改，每个人给定一个新的变更日志，分别记录每个人对文件的修改。

提供一个合并的功能，根据两份变更日志，不同的变更合并在同一个文件上，这个文件就是最终的最新版本。如果出现冲突（两份变更日志对该文件的同一行进行了修改）则让作家来决定保留哪个。

将方案三用软件的形式实现出来，就是git。但仍不完美，假设作家和多个协作者只有一台电脑，那这个方案是可行的，大家轮流用（一般不会吧）如果他们每人有台电脑（也应该是这样），则这套方案必须有远程本地多个版本存在，又出现了交互和同步的问题。

方案四：

在方案三的基础上，将文件和变更日志保存在服务器上，所有协作者都从服务器上下载这两者然后在自己的电脑上进行修改，之后再将自己本地的变更日志推送到服务器上，服务器根据这个变更日志对远端的文件进行相同修改。最终，由作家将大家服务器上不同的变更日志合并成同一个最终版本的文件。

加上远程版本和本地版本，就是git的全部思想了。

基本概念

git中有很多基本概念，我们可以类比上文的例子来理解。

• 分支：就是故事中的变更日志，每一个分支对应一个人的变更日志。当然这里一个人也可以有多个分支，这里的分支在实践中多和功能挂钩，比如开发一个新功能，修复一个bug都新建一个分支来处理
• 所有者owner：就是故事里作家的概念，owner有比较高的权限，可以决定合并如何进行
• 远程仓库：就是服务器上用来存储多个更新日志和文件的地方
• 本地仓库：就是各个协作者个人电脑上存储文件和更新日志的地方
• 确认更改：当协作者改写完文件，需要一个确认更改的操作，这样就会把这些更改真正写入更新日志里面，才会和之后的任何地方进行合并
• 提交：将本地的修改推送到服务器上的操作

  安装

mac和linux系统下推荐用brew来进行安装

brew install git

一个项目

下面用一个项目的形式介绍git的最佳实践，一般多人协作的开发方式都是按照这个流程来使用git的。

新项目创建

如果你是项目的创始者，则从你自己的电脑开始，创建你的项目（本文创建gitDemo这个项目）。写入一些初始化的文件，比如readme。

然后在这个项目的根目录运行

cd gitDemo
git init

这样就创建了一个git的本地仓库。
然后配置ignore文件来忽略项目中不需要版本控制的文件，一般是系统生成的文件，保密的配置文件等等。

touch .gitignore
vim .gitignore

之后在本地确认这些更改

git add .
git commit -m "first commit"

在远端仓库创建同名项目，这个远端仓库可以是私人搭建的，公司内部的git仓库，或者是github。

此处以GitHub演示，一般的git管理网站都类似

如图创建新的项目，只有仓库名称填写即可。

创建完成后仓库是空的，显示如下：

因为我们本地已经有了项目，所以执行红框内的命令即可。

也可以先在github创建空项目，然后按照红框上面的步骤拉取到本地。

新设备使用

这里插入一下新设备使用方式，如果你当前的电脑从来没有和github交互过，这里需要进行一个ssh key的配置，配置后本电脑只要选择ssh形式的项目（下文项目拉取部分解释）拉取，就无需输入账号密码，直接拉取即可。

首先在本机生成公钥和私钥

ssh-keygen

一路回车运行完毕后，复制出生成的公钥

cat ~/.ssh/id_rsa.pub

将上面命令返回的结果复制
进入github这个页面

点击新建，将刚才复制的key粘贴，并且取个名字

保存即可。

这里是以github为例，其他git远程仓库网站也要添加公钥才可以识别这台设备。

另外，这个ssh key还可以用在远程登录服务器上。

新项目推送

按照上面图片中的步骤将本地项目推送到对应的远端仓库

git remote add origin 远程仓库的地址
git branch -M main
git push -u origin main

结束后会发现对应的文件已经被推送到了远程仓库中，在master或者main分支下（由于zzzq，之前的master被改成了main，无语~）

老项目拉取

假设现在有个新人加入了你的项目开发，那么他不需要新建项目，拉取这个就可以。推荐用ssh的形式进行拉取，免去密码。具体如下：

复制这个ssh的地址，类似git@xxx

然后打开本地目标路径，比如这个项目是gitDemo，新人想把项目放在/Users/xinren下面，则先进入xinren这个文件夹，然后用命令clone拉取

cd xinren
git clone 前面复制的地址

开发流程

拉取成功后，拉下来的代码就成为了你本地的main分支，可以直接在上面修改，然后推送，但一般不推荐这样操作，需要新建分支开发。

一般的开发流程如下：

1. 从main新建一个分支，分支名称写明作用，比如feature/add new function 表示添加新的特性 fix:xxx 表示修复之前的bug。另外还可以再加上对应开发人员的名字在分支名称里
2. 在对应的新分支进行相应的开发工作
3. 结束后在本地仓库确认，然后推送到远程仓库的同名分支
4. 提交合并申请让owner审核，owner审核无误后合并进main分支
5. 删除远端和本地的这个开发分支
   具体操作：

新建分支切换分支:

git branch feature/add-new
git checkout feature/add-new

确认更改，并且推送到远程的同名分支

注意，初次推送远程没有这个分支，命令不同

## 添加所有更改到本地仓库
git add .
## 提交更改到本地分支，后面带着这次提交的描述
git commit -m "new feature"

## 提交到远程仓库，首次需要指定远程分支
git push --set-upstream origin feature/add-new

## 二次提交，无需指定
git push origin

之后就可以在页面提交merge request以及后续的合并操作。