Git版本控制

Yng Forever

于 2025-03-09 18:56:18 发布

阅读量856

点赞数 31

文章标签： git

本文链接：https://blog.youkuaiyun.com/2301_77206753/article/details/146136093

版权

1.概述

版本控制是一种记录一个或若干个文件内容变化,方便将来查看版本修订情况(一个或若干个文件的历史修改记录)的系统,简称VCS(Version Control Systems)

2.版本控制优点

使用版本控制可以方便记录文件的修改版本
回溯到任一历史状态
方便查看文件的修改细节,定位具体修改位置
即使文件被删除,也可以恢复到原始状态

其实学习git版本控制主要就是：

从远程仓库中克隆代码到本地仓库
从本地仓库中checkout代码然后进行代码修改
在提交前先将代码提交到暂存区
提交到本地仓库。本地仓库中保存修改的各个历史版本
修改完成后，需要和团队成员共享代码时，将代码push到远程仓库 :::

官网下载Git - Downloads和配置系统环境：

配置完成后就可以在cmd中进行测试，是否安装成功。

3.Git远程仓库托管

如何搭建Git远程仓库呢？我们可以借助互联网上提供的一些代码托管服务来实现，其中比较常用的有GitHub、码云(gitee)、GitLab等。

GitHub是一个面向开源及私有软件项目的托管平台，该平台只使用了Git进行版本控制,所以叫github

码云是国内的一个代码托管平台，由于服务器在国内，所以相比于GitHub，从码云克隆代码的速度更快

我们这里为了方便大家使用选用码云,码云和github操作差不多

注册码云,就像普通网站注册一样,不再赘述
创建公有仓库

其实就是注册一个gitee的账号，方便后期本地仓库与远程仓库关联使用。

4.Git常用命令

初始化环境：

#用户信息配置,git每次提交都会使用这个配置信息
git config --global user.name 账号名
git config --global user.email 自己的邮箱

#查看配置信息
git config --list

创建本地仓库：

#创建myrepo文件夹,作为仓库
mkdir myrepo

cd myrepo

#使用git命令初始化本地仓库,初始化成功后,myrepo下会有一个.git的隐藏文件夹
git init

从远程仓库clone，从码云克隆到/home下：

#进入到本地仓库的文件夹下进行操作
cd 自己的本地仓库路径

#git clone命令
#其实就是联网下载,将远程仓库克隆到本地成为本地仓库
#仓库名作为根目录
#根目录中会生成.git的隐藏文件夹
git clone 自己的远程仓库地址(https://gitee.com/XXXXX)

从码云克隆别人开放的工程(从github克隆,克隆快慢取决于网速 )：

git clone https://gitee.com/xiweicheng/chattool.git

理解工作目录,暂存区,版本库:

工作目录(工作区,workspace):包含.git文件夹的目录就是工作目录，一般就是我们的工程目录
版本库(version database):名叫.git的目录,保存提交的数据,元素数据,日志等信息
暂存区(stage/索引):是一个文件,保存下次将要提交的文件列表信息

Untracked(未跟踪):

此文件在工作区中, 但并没有加入到git库, 不参与版本控制. 例如:新建的文件

Unmodify(未修改):

文件已经入库, 未修改, 即版本库中的文件内容与工作区中文件完全一致. 例如:刚克隆下来的文件 README.md

Modified(已修改):

文件已修改, 仅仅是修改, 并没有进行其他的操作例如:修改README.md的内容

Staged(暂存):

修改完文件，我们执行git add，这个时候文件就变为已暂存状态

#查看仓库的状态
git status

#此时在本地仓库新建一个1.txt

#简洁输出(可以查看1.txt的状态)
git status -s

#将1.txt加入暂存区,此时1.txt由未跟踪状态转换成了暂存状态
git add 1.txt

#如果后悔了,将1.txt再由暂存状态还原为未跟踪状态
git restore --staged 1.txt 

#重新将1.txt加入暂存区,此时1.txt由未跟踪状态转换成了暂存状态
git add 1.txt

#提交1.txt到本地仓库
#如果后面不跟1.txt,会提交在暂存区的所有文件
git commit -m "commit 1.txt" 1.txt

git status

#查看历史提交记录
git log

文件的删除与恢复：

#删除工作区的1.txt
git rm 1.txt

git status

#从暂存区中恢复1.txt
git restore --staged 1.txt  只是恢复删除的状态
git restore 1.txt  在工作区中恢复

#进入到暂存区
git rm 1.txt

#提交修改,清空暂存区中的1.txt
git commit -m "删除1.txt" 1.txt

#如果这个这个删除已经从暂存区提交到版本库
#考虑从提交历史记录中恢复1.txt
#查看提交记录
git log 

#撤销xxx之前的add,commit操作,恢复到暂存区
git reset a874 

#从暂存区恢复1.txt
git restore 1.txt

操作远程仓库

查看远程仓库

如果想查看远程仓库服务器，可以运行 git remote 命令。它会列出指定的每一个远程服务器的简写。如果已经关联了远程仓库，那么可以看到一个 origin名字，这是 Git 克隆的仓库服务器的默认名字

#查看关联的远程仓库的名字
git remote

#查看具体的远程仓库地址
git remote -v
#本地仓库没有关联远程仓库
cd myrepo

git remote

git remote -v

拉取&抓取&推送

fetch抓取

#建立一个工作区文件夹
mkdir HelloGit02

#初始化本地仓库
cd HelloGit02/
git init

#建立本地仓库和远程仓库的连接
git remote add origin https://gitee.com/synchronized_zh/HelloGit02.git
git remote -v
#从origin/master分支中抓取内容到版本库,不会merge到工作区
git fetch origin master

#将抓取的内容合并到工作空间
git merge origin/master

pull拉取(fetch+merge)

#建立一个工作区文件夹
mkdir HelloGit02

#初始化本地仓库
cd HelloGit02/
git init

#建立本地仓库和远程仓库的连接
git remote add origin https://gitee.com/synchronized_zh/HelloGit02.git
git remote -v
#从origin/master分支中抓取内容到版本库,不会merge到工作区
git fetch origin master

#将抓取的内容合并到工作空间
git merge origin/master

push推送到远程仓库

我们以推送一个maven工程为例,它的流程是先从工作区---提交--->本地仓库---推送-->远程仓库

由于我们并不想把maven工程中所有的文件都推送,例如 .class文件,测试文件,日志等,只是想推送.java和配置文件,如果一个个挑选提交,然后推送,太过于繁琐,我们考虑让Git帮我们自动筛选,需要忽略文件或目录的规则

我们需要在工作区下新建一个.gitignore的文件
在.gitignore中书写忽略规则
常用规则如下:

###maven工程使用的.gitignore规则

#在工作区目录下新建.gitignore文件
#忽略target目录
target/

#忽略test目录
test/

#忽略日志文件
*.log
初始化xxxxx.gitignore

cd xxxx

#初始化本地仓库
git init

#新建.gitignore 写入以下内容
target/
test/
*.log

#将所有源码等文件添加到暂存区
git add .

#查看暂存区文件
git ls-files
#提交到本地仓库
git commit -m "第一次提交xxxx工程" .

#查看提交记录
git log
#关联远程仓库
git remote add origin xxxx远程仓库地址
git remote -v


#推送到远程仓库
#在push的时候需要输入码云的账号和密码 或者 需要修改windows凭据
#-f 强制推送,如果不加,那么会要求先pull拉取远程仓库的代码与本地代码合并,再push
git push origin master -f

Git分支

分支概述

在对版本库进行最初的提交后，Git会默认建立一个名为master的分支。之后的提交在切换分支之前都会增加在master分支里。|

| --- | --- | |

为了让仓库群组的成员的开发相互之间不受影响，可以在主要分支基础上建立自己专用的分支。完成开发的成员们，将自己分支的修改导入到主要分支，这样大家都可以不受其他成员的影响，导入自己的修改内容。而且每个提交的历史记录都会被储存，当发生问题时，可以更容易找到发生问题的地方。 :::

查看分支

#查看本地分支
git branch

#查看远程分支
git branch -r

#本地分支+远程分支
git branch -a

创建,切换,推送本地分支

#创建dev分支
#如果当前指向master分支,那么创建的dev分支会拷贝master分支下所有的内容
git branch dev

#查看本地分支
git branch

#切换到dev分支
git checkout dev

#将dev推送到origin远程仓库
git push origin dev

dev中的文件和master中的文件刚开始是完全相同的,因为就是在master分支的基础上衍生出来的,但是随着开发的推进,例如我在dev上开发未上线的功能,master只放发布功能,那么两者代码就开始产生不同

合并分支与解决冲突

合并分支

#切换到dev分支
git checkout dev

#在dev分支中的day02-maven-ssm的src/main/java下添加一个Person.java
public class Person{

}

#添加到暂存区然后提交到dev分支下
git add src/main/java/Person.java
git commit -m "添加 Person.java" src/main/java/Person.java


#切换到master分支,此时master分支下并没有Person.java
git checkout master

#将dev分支合并到master分支
#合并后master分支中也有dev新加的文件
git merge -m "第一次将dev分支内容合并到master分支" dev

产生合并冲突

如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git就无法合并它们,因为GIT不知道你是要将两者内容合并还是其中一个覆盖另一个等操作,所以Git会产生冲突,这个冲突需要我们手动解决

#切换到master分支,修改Person.java
git checkout master

#修改Person.java为以下代码
public class Person{
    private String name;//master分支添加的属性
}

#提交master分支
#对于修改后的文件可以直接commit,当然也可以先add再commit
git commit -m "master分支修改Person.java" 相对路径


#切换到dev分支,修改Person.java
git checkout dev

#修改Person.java为以下代码
public class Person{
    private int age;//dev分支添加的属性    
}

#提交到dev分支
git commit -m "dev分支修改Person.java"相对路径


#切换到master分支
git checkout master

#将dev分支合并到master上
#此时就会产生冲突
git merge -m "将dev分支合并到master分支" dev

解决合并冲突

#在master分支上修改冲突文件
#这里我们修改为合并两个属性,当然也可以删除某个属性,完全取决开发者需求

#重新提交
#此时后面不能带Person.java,这里要提交所有修改
git add 路径

git commit -m "解决了合并冲突"
重新推送master和dev分支

  #推送本地所有分支(master,dev到origin远程仓库)
  git push origin --all

IDEA中使用Git

IDEA中配置Git

由于我们要在windows下的IDEA中使用git,所以需要下载git的windows版,然后指定git.exe的路径,测试成功即可

IDEA中工程创建,添加,提交,推送

创建一个maven工程
启用git进行版本控制启用后,相当于执行 git init指令,在工程根目录生成.git隐藏文件夹
提交GitDemo工程 Ctrl+K 提交, 提交后可以在log界面(git log)看到提交历史记录
推送到远程仓库

IDEA克隆远程仓库

IDEA从远程仓库拉取

在远程仓库的新建,并做了提交
本地仓库已经不是最新版本,因此做pull动作,从远程仓库拉取最新内容
提交+推送

IDEA中版本对比与还原指定版本

如果我们修改git-demo中的文件,添加了xxx属性,并提交

将当前版本的文件与之前的版本的文件做比较

此时我们后悔了,想要还原到之前的版本
- soft：完全保留工作区和暂存区，会撤销git commit提交，保留git add操作
- mixed：完全保留工作区，会撤销commit提交和 git add操作
- hard：工作区恢复到所选的commit的状态 , 之后的commit和改动全部丢弃
- keep：keep 类似于 hard，但如果在工作目录中有未提交的改动，keep会保留这些改动，而 hard会丢弃这些改动。