Git笔记

最新推荐文章于 2024-06-24 09:39:54 发布

总耳凡工

最新推荐文章于 2024-06-24 09:39:54 发布

阅读量199

点赞数

分类专栏：版本管理及构建文章标签：代码git托管

本文链接：https://blog.csdn.net/kepus/article/details/79518429

版权

版本管理及构建专栏收录该内容

2 篇文章 0 订阅

订阅专栏

1. 本地仓库 / 本地版本库

不与他人协作开发，不与远程代码库交互，代码的增、删、改的记录全部发生在本地，功能类似SVN.

这里写图片描述
1.1 创建版本库

版本库的标志是目录下有 .git 目录

//将当前目录变为git仓库
$ git init
Initialized empty Git repository in D:/gitRepository/.git/

//将文件添加到版本库，此时磁盘上的文件应该有 蓝色加号 标识
$ git add readme.txt

//文件提交到版本库，此时磁盘上文件应该有 绿色对号 标识
$ git commit -m 'init file: kobe'
[master (root-commit) f8b527c] init file: kobe
 1 file changed, 1 insertion(+)
 create mode 100644 readme.txt

1.2 查看版本库状态

文件被纳入版本控制后的状态有：修改未暂存、暂存未提交、提交未推送（推送涉及远程库，本地仓库的话提交是最终状态）

//查看版本库当前状态
$ git status
On branch master    （当前分支）
Changes to be committed:  （已暂存，等待提交）
  (use "git reset HEAD <file>..." to unstage) （可以git reset HEAD 取消暂存）

        modified:   readme.txt

Changes not staged for commit: （修改还没有暂存）
  (use "git add <file>..." to update what will be committed) （可以git add 暂存）
  (use "git checkout -- <file>..." to discard changes in working directory) （可以git checkout -- 取消修改）

        modified:   desc.txt

//比较工作区文件的变化（文件修改后）
$ git diff

//比较暂存区文件的变化（文件修改并git add后）
$ git diff --cached

1.3 撤销修改

文件未提交前的恢复操作叫撤销修改，有2中情况：撤销工作区的修改（文件修改但没有添加到暂存区）、撤销暂存区的修改（文件修改后添加到暂存区但没有提交）

//撤销工作区修改
$ git checkout -- readme.txt

//撤销暂存区修改
$ git reset HEAD readme.txt  （相当于撤销git add操作）
$ git checkout -- readme.txt （将文件回退到修改前）

1.4 版本回退

git的一个个快照指的是一次次的commit提交操作,文件一旦提交到版本库后，是无法撤销修改的，只能通过版本回退来恢复修改.

//查看提交历史
$ git log --pretty=oneline
3b7f2db821074477692333c9b9dca07eecba160f desc reade 2 commit
a30a08ef1893557fc4cf4b424f9b5c38bc64ede6 init empty desc.txt
f8b527c2e2fdf2840e14695ff7fea8f0689f549c init file: kobe
(前面为comimtID，后面是提交时的描述信息)


//回退到init file: kobe版本，也就是回退2个版本
//方式1
$ git reset --hard HEAD^^   （^的数量标识回退的版本个数）
HEAD is now at f8b527c init file: kobe  （f8b527c 为对应commitId的头几个字母）

//方式2
$ git reset --hard HEAD~2 （2表示回退2个版本）
HEAD is now at f8b527c init file: kobe

//方式3
$ git reset --hard f8b527c2e2fdf2840e14695ff7fea8f0689f549c
HEAD is now at f8b527c init file: kobe

1.5 创建分支
这里写图片描述

master分支要保持稳定用来发布版本，所以一般不在master上面开发需求，而是拉取dev分支进行开发，当需求开发完成需要发布时，再从dev分支合并到master分支进行发布.

//创建分支
$ git branch dev

//切换分支
$ git checkout dev
Switched to branch 'dev'

//删除分支（先切换到其他分支）
$ git branch -d dev
Deleted branch dev (was 00f5589).

//创建并切换分支
$ git checkout -b dev
Switched to a new branch 'dev'

//查看所有分支，*标注当前所在分支
$ git branch
* dev
  master

1.6 分支合并

在dev分支对文件所做修改并提交后，切换到master分支，合并之前在master分支是看不到dev分支的修改的；

合并要切换到主分支进行操作，例如将b分支的修改合并到a分支，需要切换到a分支操作

//在dev分支新建、添加并提交文件
//切换到master分支
$ git checkout master
Switched to branch 'master'
//合并前日志
$ git log --pretty=oneline --graph
* f8b527c2e2fdf2840e14695ff7fea8f0689f549c init file: kobe

//进行合并（默认尽可能用快速移动，将master指向dev的提交）
$ git merge dev
Updating f8b527c..4eab416
Fast-forward
 dev.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 dev.txt

//删除dev分支前查看提交日志
$ git log --pretty=oneline --graph
* 4eab416b54a61d15c5273197f6766ca4306cb489 add dev.txt in dev branch
* f8b527c2e2fdf2840e14695ff7fea8f0689f549c init file: kobe

//禁用Fast-Forward方式合并,这种方式会在master分支额外增加一条commit记录
$ git merge --no-ff -m 'merge dev no-ff' dev
Merge made by the 'recursive' strategy.
 dev.txt | 1 +
 1 file changed, 1 insertion(+)

1.7 解决冲突

在主线拉取dev分支后，dev修改了a.txt文件，同时其他人也修改了a.txt文件并合入到master分支，此时如果master分支合并dev分支时就会产生冲突.

//创建并切换到dev分支，编辑dev.txt并提交
$ git checkout -b dev
Switched to a new branch 'dev'
$ git add dev.txt
$ git commit -m 'edit dev.txt in dev branch'
[dev 5db773e] edit dev.txt in dev branch
 1 file changed, 1 insertion(+)

//切换到master分支，编辑dev.txt并提交
$ git checkout master
Switched to branch 'master'
$ git add dev.txt
$ git commit -m 'edit dev.txt in master'
//master分支查看日志
$ git log --pretty=oneline --graph
* a136bf3fee820fb699ddc7b6a708bdf33283f036 edit dev.txt in master
* 4eab416b54a61d15c5273197f6766ca4306cb489 add dev.txt in dev branch
* f8b527c2e2fdf2840e14695ff7fea8f0689f549c init file: kobe

//执行合并，发现冲突
$ git merge dev
Auto-merging dev.txt
CONFLICT (content): Merge conflict in dev.txt
Automatic merge failed; fix conflicts and then commit the result.

//编辑dev.txt解决冲突
HEAD和======之间是master分支内容
dev和======之间是dev分支内容
按照实际情况解决冲突

//添加并提交冲突文件
$ git add dev.txt
$ git commit -m 'solve conflit in dev.txt'

//查看提交记录

这里写图片描述

2. 远程仓库

多人协作时用到远程仓库，编码后提交到本地仓库，然后推送到远程仓库，别人就可以从远程仓库获取到你的代码;
可以自己在linux上搭建一个远程仓库，也可以使用类似github、码云等远程仓库.

2.1 本地仓库和远程仓库建立关联关系

需要有自己的远程仓库，并建立项目，可以在码云上面建立：https://gitee.com/gongcong/gitRepository.git

本地仓库和远程仓库关联有2种情况：
1.已有远程仓库要建本地仓库（多是这种情况，例如项目组增员）;
2.已有本地仓库要建远程仓库；

origin为远程库的名字，一般都指定为这个，当然也可以自己指定，但是强烈建议用origin

//已有远程仓库：代码克隆（默认关联master分支）
$ git clone https://gitee.com/gongcong/gitRepository.git
//克隆指定分支(dev)到本地
$ git clone -b dev https://gitee.com/gongcong/gitRepository.git
//如果原先已经克隆分支（master）到本地，可以检出新的分支并关联
$ git checkout -b dev origin/dev
Branch dev set up to track remote branch dev from origin.
Switched to a new branch 'dev'

//已有本地仓库
//建立关联
$ git remote add origin https://gitee.com/gongcong/gitRepository.git
//拉取远程库中初始代码
$ git pull origin master --allow-unrelated-histories
//推送到远程库
$ git push origin master

//查看远程库信息
$ git remote -v
origin  https://gitee.com/gongcong/gitRepository.git (fetch)  (拉取权限)
origin  https://gitee.com/gongcong/gitRepository.git (push)   (推送权限)

2.2 团队开发

团队开发一般情况是远程仓库及分支已经存在，开发人员只需要从远程仓库克隆到本地，进行开发然后推送到远程仓库即可

//克隆分支、检出新分支参考2.1
//推送分支-本地仓库和远程仓库没有冲突，推送成功
$ git push origin dev  （远程仓库名 分支名）
//更一般的情况是，推送时有同事修改了相同的文件并推送到远程仓库，此时会推送失败，需要先进行拉取操作
$ git push origin dev
To https://gitee.com/gongcong/gitRepository.git
 ! [rejected]        dev -> dev (fetch first)  （提交失败）
error: failed to push some refs to 'https://gitee.com/gongcong/gitRepository.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again. （推送前先拉取）
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

//拉取分支
//如果本地分支和远程分支没有建立联系，进行拉取操作会报There is no tracking information for the current branch错误，可以通过$ git branch --set-upstream-to=origin/dev dev 来建立联系
//此时拉取分支后一定会有冲突文件
$ git pull
CONFLICT (content): Merge conflict in desc.txt （冲突文件）
Automatic merge failed; fix conflicts and then commit the result.
//类比1.7解决分支间冲突来解决拉取的冲突并添加、提交、推送到远程库

2.3 暂时存储修改

有一种场景是需求A还没开发完，部分文件已经修改或保存到暂存区（没有提交），这时来了一个更紧急的需求B，这就需要把A需求的所有修改先暂时保存，开发B需求，等B需求开发完毕代码推送到远程库后再取出需求A的暂存代码继续开发

//暂存
$ git stash save 'stash reademe.txt'
Saved working directory and index state On dev: stash reademe.txt
HEAD is now at c6b7040 solve conflit
//查看暂存
$ git stash list
stash@{0}: On dev: stash reademe.txt
//恢复并删除暂存
$ git stash pop