当前位置:   article > 正文

Git 版本控制/项目迭代_git为什么那么多版本

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配置(常用

  1. git config --global user.name "zhangsan"
  2. 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(ourstheirs)的公共祖先, 也就是在gitlab的network界面中,回溯两个分支的commit线,一直到岔路口)三个版本的文件进行比较,获取ours和ancestor的diff,以及theirs和ancestor的diff,这样做能够发现两个不同的分支到底做了哪些改动。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/你好赵伟/article/detail/457486
推荐阅读
相关标签
  

闽ICP备14008679号