Git 版本控制/项目迭代

一、Git的作用/为什么要进行版本控制？

什么是项目迭代？

搞开发的时候我们不是一次性就做好平台的所有功能，而是先上线一个功能差不多的版本让用户用着，然后不断迭代、修改，上线新的版本，所以一个项目就会出现很多版本。

借用风哥的话说就是“小步快跑”，所以总是在加班

为什么要进行版本控制？

原因（1）：我们对项目进行了七八轮的修改，最后发现还是最初的版本好用！但是我们不想再手动改回去，况且我们也忘了自己都改了什么，这就需要一个仓库去记录之前的历史版本。恢复到以前的版本可以理解为回滚。

原因（2）：提升多人开发效率

二、git的诞生

Linux内核发布早期，难免很多错误，Linux社区的大佬们在体验Linux的过程中会发现这些错误，自己打补丁，给作者提交新版本的Linux内核。如果一天有100个大佬提交了100个补丁，那作者就要手动归档100次。

所以Linux的作者开发了Git。

仅用了两周，并且也是开源、免费的。

三、git的安装

超棒的教程：

Git 详细安装教程（详解 Git 安装过程的每一个步骤）_git安装_mukes的博客-CSDN博客

官网下载安装包会很慢，找国内镜像下载。

无脑next安装。

安装程序会自动配好环境变量，但是没啥用。

四、git bash  git cmd 和 gitGUI

只需要知道git bash是最重要的就行了，其他两个用不到

五、git的必要配置

        用户名和邮箱是必须要配置的，不然别人怎么知道新版本是谁提交的？

        Git的配置又分为修改整个系统的配置(system)和修改当前用户的配置（global），我们只需要改global的就可以了。

        有两种修改方式。

法（1）git bash命令行修改

1. 修改system配置

不用管。

2. 修改global配置（常用）

git config --global user.name "zhangsan" 
git config --global user.email "zhangsan@jd.com"

查看配置信息 ，检查一下是否修改正确

git config --list

法（2）直接改配置文件

git系统的配置文件和用户的配置文件不在一个地方

1. 修改系统配置

 2. 修改用户配置

六、git是否要配环境变量？

都行。

因为git使用的时候一般是，先打开想要存放项目的文件夹（我们已经自己定位好了），然后右键选择git bash，所以其实不需要配环境变量。

七、git工作一览图

八、配置SSH-key

https://blog.csdn.net/qq_44886213/article/details/129841419

九、git常用操作

1. 在本地新建仓库

PS: 如果这个项目只是你自己在开发，那么一个本地仓库就够了，远程仓库是多人开发一个项目才能用到。

新建一个工作目录，打开git bash执行如下命令

git init

工作目录下就会出现一个.git文件夹，表明本地仓库新建成功。

2. 克隆远程仓库

更多情况下，我们不是项目的发起者，不需要自己建仓库，直接拉取同事建好的就行了。

git clone url

3. 提交到暂存库

我们改动了代码

git add .  #最后一个点的意思是，把工作目录下的所有文件都提交到暂存库

其实不用提交所有文件，因为我们一般只改了其中一两个文件。用 add . 是为了方便。后续在IDEA中使用git时，会直接帮我们识别改动了什么文件，不需要再执行git add命令了。

4. 提交到本地仓库

git commit -m "我改了什么东西"

5.提交到远程仓库

git push

6. git的提交过滤（.gitignore文件）

我们不想把工作目录的所有文件都进行版本控制，比如数据库文件，IDEA自己生成的.idea文件，日志文件，target下的文件，因为这些文件也不需要版本控制

7. 更新

如何获得别人最新提交的版本。

分为两种情况，一种是你一点也没改，这样可以直接check out，check out虽然会合并你的版本和该分支当前提交的最新版本，但是由于你什么都没有改，所以就相当于拉取了最新的版本；还可以把项目文件夹全都删了，重新Git clone。另一种情况是你改了代码，此时check out的话，就需要和最新提交的版本合并。

 十、IDEA中git的使用

git clone一个项目，然后直接用IDEA打开。

PS：git项目可以直接复制粘贴文件，比如说我们的项目目前在D:/workspcae/jdmeta下，我因为是用git clone拉去下来的，所以git可以在该目录下生效，可以用git commit/push命令提交，但是现在我们想把项目移动到D:/workplase/jdmeta2下面，只需要把D:/workspcae/jdmeta下的所有文件都复制粘贴到D:/workspcae/jdmeta2下就行了，只要包括了.git文件夹，git在新目录下照样生效。因为.git文件夹中的文件记录着这个项目的远程仓库地址，

git的操作只需要记住3步：

1. git add
2. git commit
3. git push

 

十一、分支问题

1、git有一个中心仓库，库中有一个产品A的设计图纸，这个就是master。

2、码农A和B打算改进产品A；于是他们从仓库下载原始图纸到本地，然后在本地修改

3、码农A做出初步改进后打算提交，若其它任何码农均未提交，则可以直接提交；但却发现码农B已经提交自己的版本了

4、码农A认为自己的改进其实还有地方需要完善；那么如果每次合并主版本都要检查并合并B的修改（以及之后可能有的其它修改），显然会浪费很多时间，耽误后续开发；若草草检查就合入，就容易影响主版本的稳定。

5、于是码农A产生了一个分支，叫做产品A之码农A改进版；以后自己的改进都合进这个分支

6、码农B、C、D继续改进产品A的master版

7、N个月后，码农A认为自己的改进已经尽善尽美了，于是合并自己的“产品A之码农A改进版”到当前的主版本

8、但是两者冲突太多；于是码农A利用各种diff工具检查主版本和自己的分支版本之异同，注意观察自己的代码能否直接插入主版本而不引起逻辑故障；若不引起就合入，否则可能就要前后错几行、在合适位置合入。

9、合入后，经过重新测试，码农A就可以废止自己的分支版本，新功能开发完成。

10、任何参与开发的人，只要不是一次性修改，都应该这样开一个分支，把自己的工作先合入这个分支；等开发完全完成后再合并自己的分支到主版本。

简单来说：master只能存放稳定版本，也就是能够通过编译测试的版本。如果码农A要在master的基础上增加一个新的功能，并且预计两个周的时间，要改很多次，不断去修改这个功能，那么A就要新开一个自己的分支，当新功能写好了以后，再merge到master分支去。如果码农B只是对master做一下小修改，预计半小时就能改完，而且只改一两次，那么B直接在master上改就行，不用创建一个新的分支。如果码农A要在master的基础上新增一个功能，同时码农B也要在master的基础上新增一个功能，A和B都必须要新开分支，那如何merge呢？

上图中，A和maser进行merge的时候是没问题的，当B要merge到主分支时：程序员A和B坐在一起，用diff命令查看不同的地方，商量两个人的代码如何合并。

十二、git 的merge如何实现冲突检测的？（字节面试题）

git merge是怎样判定冲突的？ - spacewander - SegmentFault 思否

将ours，theirs和ancestor（ancestor是后面两个commit（ours和theirs）的公共祖先， 也就是在gitlab的network界面中，回溯两个分支的commit线，一直到岔路口）三个版本的文件进行比较，获取ours和ancestor的diff，以及theirs和ancestor的diff，这样做能够发现两个不同的分支到底做了哪些改动。