Git 使用手册

灵动鱼

已于 2023-04-09 15:27:35 修改

阅读量283

点赞数

文章标签： git

于 2023-04-07 23:48:13 首次发布

本文链接：https://blog.csdn.net/qq_41911251/article/details/130001050

版权

Git

参考廖雪峰官方网站

定义

分布式版本控制系统
Linus用C语言写的
服务于Linux、GitHub等官网

集中式vs分布式

集中式
- CVS
- SVN
分布式
- Git

安装Git

Linux
Mac OS
Window
- Git 官网下载程序，默认选项安装
- 鼠标右击---->Git Bash 出现黑色框命令行，表示Git安装成功
- git config --global user.name "你的名字"
  git config --global user.email "你的邮箱"
  注意: git config命令的**–global参数**，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置

创建版本库

什么是版本库(仓库)?
可以理解为目录，所有文件被Git 管理
创建版本库实际上就是单纯创建文件
- Windows系统初始化仓库
```
      git init 
      Initialized empty Git repository in /Users/michael/learngit/.git/        
```
是空的仓库，会多.git的文件
文件添加到版本库
跟踪文本文件的改动
第一步，用命令**git add**告诉Git，把文件添加到仓库：

	   $ git add readme.txt

第二步，用命令**git commit**告诉Git，把文件提交到仓库：

	$ git commit -m "wrote a readme file"
	[master (root-commit) eaadf4e] wrote a readme file
	 1 file changed, 2 insertions(+)
	 create mode 100644 readme.txt

时光机穿梭

要随时掌握工作区的状态，使用git status命令
如果git status告诉你有文件被修改过，用git diff可以查看修改内容

版本回退

HEAD指向的版本就是当前版本，上一个版本就是HEAD^。因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本如果嫌输出信息太多，看得眼花缭乱的，可以试试加上**–pretty=oneline参数**
要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

工作区和暂存区

工作区
电脑里的目录
版本库
工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库
暂存区
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD

例:git add ------> git commit

管理修改

在这里插入图片描述
从上一节可以了解到git add 就把第一次修改的内容，放到暂存区，然后 git commit，就把第一次修改的内容整到master去了，第二次修改的内容并没有传到暂存区和master。

在这里插入图片描述
分别将第一次修改和第二次修改内容整到暂存区，然后一起git commit ，整到master
即:每次修改，如果不用git add到暂存区，那就不会加入到commit中

撤销修改

1、工作区撤销修改

git checkout -- 文件名

2、暂存区撤销修改

git reset HEAD <file>

回到了场景1，第二步按场景1操作
3、已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库

删除文件

将工作区文件删除，会出现工作区和版本库不一致，也就会出现两种情况:

第一种情况: 版本库的文件需要删除，维持两者一致，代码为

git rm 文件
git commit -m  “提交描述”

第二种情况: 恢复工作区的文件，维持两者一致，代码为

git checkout -- 文件

git checkout 用于版本库里的版本替换工作区的版本，无论是工作区的修改还是删除

分支管理

分支作用: 创建新分支，即使工作没完成，也可以提交，确保自己数据不丢失，且不影响其他人工作

创建与合并分支

主分支(master 分支)，master指向最新提交，HEAD指向当前分支

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uGIMZMlm-1681020524445)(C:\Users\26541\AppData\Roaming\Typora\typora-user-images\image-20230408212403031.png)]

每次提交master就会往后移动，此分支也就越来越长。

创建新分支—dev

dev 指向master相同的提交，HEAD指向dev，表示当前分支在dev

提交

dev 就往后移动，HEAD还是指向dev，表示还是在dev分支

合并

master指向dev的当前提交，并将HEAD指向master分支

合并。删除dev，就剩下master指针了

创建 dev 分支，并将 HEAD指针指向 dev

git branch dev
git checkout dev

其中，git checkout 后面加上 -b 参数表示创建并切换

查看所有分支

git branch 
* dev
  master

其中，*表示当前的分支

git checkout master     // 将HEAD 指向dev
git merge dev             // 合并

合并完成后就可以删除 dev

git branch -d dev

解决冲突

有上图可知，两个分支分别修改同一文件中的内容，并都进行提交，这需要解决冲突 ，再合并。

如何解决冲突呢？

git status 查看冲突文件
cat 文件内容的冲突部分
手动更改冲突部分，并进行提交

合并分支，删除 feature1，得到如图所示，并采用带参数的git log 来查看分支的合并情况

分支管理策略

不使用Fast forward模式，合并后的历史有分支，能看出来曾经做过合并

git merge --no-ff -m "merge with no-ff" dev

–no-ff 参数，表示禁用 Fast forward
-m 参数表示本次合并要创建一个新的commit，并把commit的描述加进去

使用 Fast forward模式，看不出来曾经做过合并

实际开发中，团队合作的分支如下图所示。

Bug分支

情景：

当你接到修复一个bug的任务时，当前正在dev上进行的工作还没有提交，需要你先修bug，怎么办？

dev 的工作进行隐藏
```
git stash
```
建新分支，修复bug
用git stash list命令查看

用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除
git stash pop，恢复的同时把stash内容删掉

Feature分支

开发一个新feature，最好新建一个分支；
如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除

多人协作

查看远程库信息，使用git remote -v；
本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
从远程抓取分支，使用git pull，如果有冲突，要先处理冲突