工具&软件学习-GIT版本管理-git常规应用策略

用户昵称100

已于 2024-02-27 19:34:47 修改

阅读量209

点赞数

分类专栏：理论指导嵌入式 C/C++编程文章标签： git

于 2021-09-05 16:32:55 首次发布

本文链接：https://blog.csdn.net/qq_18661919/article/details/120116982

版权

嵌入式同时被 3 个专栏收录

21 篇文章 1 订阅

订阅专栏

C/C++编程

19 篇文章 2 订阅

订阅专栏

理论指导

12 篇文章 0 订阅

订阅专栏

git的核心思想

Git 的配置

初次运行Git前的配置

Git自带一个git config的工具设置Git外观和行为的配置变量。每台计算机只需配置一次，程序升级时会保留配置信息。可以通过命令修改它们。

/etc/gitconfig文件：
包含系统上每一个用户及他们仓库的通用配置。如果使用带有–system选项的git config时，它会从此文件读写配置变量。
_{/.gitconfig或者}/.config/git/config文件：
只针对当前用户。可以传递–global选项让Git读写此文件。
当前使用仓库的Git目录中的config文件(就是.git/config):
针对该仓库。

每一个级别覆盖上一级别的配置，所以.git/config的配置变量会覆盖/etc/gitconfig中的配置变量。

用户信息配置

文本编辑器配置

检查配置信息

/**
 * 1. 列出所有Git当时能找到的配置
 */
 git config --list

/**
 * 2. 检查Git的某一项配置
 */
 git config <key>:
 eg: git config user.name

获取帮助

获取帮助信息，无需联网

git help <verb>
git <verb> --help
man git-<verb>

eg: git help config

本地工程、仓库、分支和远程工程、仓库、分支的创建

在本地目录创建仓库并与远程仓库关联的方式一共有两种情况。1，本地目录空，远程仓库已经由他人创建。2，本地目录空，远程仓库由自己创建。3，本地目录不空（已经有初版工程），远程仓库还未创建。

前两种情况，都是采用clone方式即可创建与远程仓库相关联的本地仓库。第三种情况，则需要关联、合并本地、远程仓库。

具体操作，因为第一种实在没有什么操作，只有"git clone …",所以，我们只针对第三种情况说明。

下面是在远程仓库GitHub上创建工程的时候，添加有内容（readme），会造成远程仓库和本地仓库文件不一致时，如何操作。

GitHub端创建远程仓库
在本地工程目录，创建本地仓库
```
git init
```
添加本地文件

git add .

提交本地文件

git commit -m "message" [./filename] -a

以上都是在我们本地的工作，现在我们把更改推送到远程服务器上

关联GitHub上面的项目

1. git remote -v				//查看远程仓库
2. git remote rm origin			//删除远程仓库
3. git remote add origin {url}	//添加远程仓库， origin为给远程仓库起的名字
4. git pull origin master --allow-unrelated-histories
//如果在3就执行pull的话，远程仓库和本地仓库不相干，文件不匹配，所以警告无法合并。
//所以，第一种解决方法：从远程仓库拉下来代码，本地要加入的代码放到远程仓库下载到本地的库，然后提交
//这样的话，你基于的库就是远端的库。
//第二种解决方法：就是使用4中的强制将两段不相干的本地、远程分支强行合并
5. git push -u origin master	//如果远程仓库是空的，我们第一次推动master分支时，加上参数-u，
//git不但会把本地的master分支内容推送到远程新的master分支，还会将本地的master分支和远程的master
//分支关联起来。

下面是在创建远程仓库(github)时，没有添加任何文件。
GitHub会尽心的有如下提示：
在这里插入图片描述其中就有“or create a new repository on the command line”
然后，在git中做相应命令行操作即可实现首次仓库的创建。与上面方法的区别就在于，远程仓库为空，可以忽略pull远程仓库和本地仓库不一致问题。下面是实操效果图：
效果图第一部分
效果图第二部分
值得一提的是，其中github提示了一行”git branch -M master“；
通过”git help branch“查看git branch命令，有如下解释：
-M的参数解释就是对分支重新命名了。据说是因为黑人的政治正确,master变成敏感词汇了，哈哈。
下面重新刷新GitHub远程仓库，看是否本地仓库已经推送到远端。
远端仓库没问题！

本地工程、仓库、分支的维护和远程工程、仓库、分支的维护

版本的回退、前进

查看历史版本 “git reflog”
版本的前进和回退
- 基于索引值操作（既能前进也能后退） “git reset --hard [索引值]”
- 使用^符号(只能后退) "git reset --hard HEAD^ "。 [注]：一个^表示回退一步， n表示回退n步
- 使用~符号(只能回退) “git reset --hard HEAD~n”。 [注]：表示后退n步
reset 命令的三个参数对比
- –soft 参数：仅仅在本地库移动HEAD指针
- –mixed参数: 在本地库移动HEAD指针、重置暂存区
- –hard参数: 在本地仓库移动HEAD指针、重置暂存区、重置工作区

checkout

工作区有更改和commit本地仓库不一致，需要清除工作的更改操作，使用“git checkout .”，或者“git checkout – filename”
放弃工作区和暂存区的所有修改，使用“git checkout -f”
进行本地的分支切换，使用“git checkout [branch name]”。
远程分支的切换，使用“git checkout -b 本地分支名 origin/远程分支名”

branch

pull

push

user1 在分支A 写代码写了一半，有另一个开发者user2也开发了此分支，并已经push上去了。
那么，user1该怎么办呢？

1. git add .
2. git commit -m "xxxxxx"
3. git push 
/* 由于user2也修改，并push了此分支，会引发冲突 */
4. git pull
/* 将user2 push的代码版本 拉下来，会自动与本地代码merge */
/* 解决merge 冲突 */
4.1. git add .
4.2 git commit -m "xxxxxx"
4.3 git push

【注解】：每次的push都会检验比对文件，并生成哈希值。如果检验有问题，会产生相应冲突，否则就是git逻辑上有漏洞了。

tag

查询标签

/* 当前仓库的所有标签 */
git tag
/* 符合模式的标签 */
git tag -l ‘v0.1.*’
/* 查看标签的版本信息 */
git show v0.1.2

创建标签

有两种类型的标签：轻量标签（lightweight）、附注标签(annotated)
【轻量标签】：只是某个commit 的引用，可以理解为是一个commit的别名；
【附注标签】：是存储在git仓库中的一个完整对象，包含打标签者的名字、电子邮件地址、日期时间以及其他的标签信息。
它是可以被校验的，可以使用 GNU Privacy Guard (GPG) 签名并验证。

创建轻量标签
git tag 标签名：直接给当前的提交版本创建一个【轻量标签】
git tag 标签名提交版本号：给指定的提交版本创建一个【轻量标签】

/* 以当前提交版本创建【轻量标签】 */
git tag v4.0
/* 以指定版本【7864852】创建【轻量标签】 */
git tag v3.0 7864852

创建附注标签
-a : 理解为 annotated 的首字符，表示附注标签
-m : 指定附注信息
git tag -a 标签名称 -m 附注信息：直接给当前的提交版本创建一个【附注标签】
git tag -a 标签名称提交版本号 -m 附注信息：给指定的提交版本创建一个【附注标签】

/* 以当前提交版本创建【附注标签】 */
git tag -a v3.0-release -m "里程碑版本 3.0 正式发布"
/* 以指定版本【f568452】创建【附注标签】 */
git tag -a v2.0-release f568452 -m "里程碑版本 2.0 正式发布"

提交标签

通常的git push不会将标签对象提交到git服务器，我们需要进行显示的操作

/* 单个 */
git push origin v1.0.2
/* 所有 */
git push origin --tags

切换标签

git checkout [tagname] ：切换到标签版本
git checkout -b [分支名称] [tagname] ：现在这个标签基础上进行其他开发。就是以标签指定的版本为基础版本，创建一个新分支，继续其他操作，即创建新分支。

/* 切换到标签版本 */
git checkout v5.0

/* 以标签为基础创建一个新分支 */
git checkout -b bug-fixed-3.0 v5.0-release

删除标签

git tag -d 标签名称：删除指定名称的本地标签
git push origin :regs/tags/标签名称：删除远程标签
git push origin --delete 标签名称：删除远程标签

/* 删除本地标签 */
git tag -d v0.1.2
/* 删除远程标签 - 就像git push origin :branch_1 可以删除远程仓库的分支branch_1一样， 冒号前为空表示删除远程仓库的tag */
git push origin :refs/tags/v1.0.1
/* 删除远程标签 */
git push origin --delete v1.0.1

使用策略

merge

有冲突的情况说明。

user1 和user2 各改各的地方（相同文件），不冲突。
user1 和user2 各改各的文件，不冲突。
user1 移动文件，user2 不移动文件， git 不显示冲突。但是需要我们人为备注，注意。
user1 和user2 修改相同文件的相同地方，引起冲突，并且git提示冲突。

由于在merge过程中，不能仔细斟酌它默认保留的冲突代码是否是我们想要的，或者手动解决的冲突，是否完整，想要查看。可以通过以下操作查看。

a. 通过show命令
git log 查看merge 的哈希值
在这里插入图片描述
git show 查看更改

b. 通过git log -p

rebase

分支合并push

1.修改程序，commit “1.1.7”—》修改程序，commit “1.1.8”—》修改程序， commit “1.1.9”
2.右键本地仓库，bash here ：git rebase -i HEAD~3 —>显示下图
在这里插入图片描述
按键‘i’—>进入编辑界面，底层有提示“-- INSERT --”
修改’pick xxxx’ —>‘squash xxxx’ ，如下图：

按Q退出编辑，然后输入:wq +enter键，保存退出编辑界面，运行后界面显示图下：
在这里插入图片描述

输入:wq ,保存退出vim界面，返回git命令界面，显示图下：
在这里插入图片描述
3，push合并的分支
在上面的git页面继续键入：
git push origin xxx指令

4，运行前后效果

前：
在这里插入图片描述
后：

发现只push了一个1.1.7节点，其实这一节点是1.1.7、1.1.8、1.1.9合并的。但是由于显示长度问题，只显示最早的信息描述。
点进去，效果如下：
在这里插入图片描述

git diff

git merge 之后有冲突，显示“|merging ”，想查看哪些文件冲突了，怎么办？

```cpp
git diff --name-only --diff-filter=U
```

参考官网【】
–name-only (仅仅列出改变的名字)
: show only names of changed files. The file names are often encoded in UTF-8.For more information see the discussion about encoding in the git-log[1] manual page.

–diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]
:
过滤器，U是仅仅显示Unmerged.

用户昵称100

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
工具&软件学习-GIT版本管理-git常规应用策略

git常规应用策略git的核心思想本地工程、仓库、分支和远程工程、仓库、分支的创建本地工程、仓库、分支的维护和远程工程、仓库、分支的维护branchpullpushmergerebasegit的核心思想本地工程、仓库、分支和远程工程、仓库、分支的创建本地工程、仓库、分支的维护和远程工程、仓库、分支的维护branchpullpushmergerebase.........
复制链接

扫一扫