Git

1、Git基本概念

  • repository
  • config
  • init
  • clone
  • fetch
  • pull
  • commit
  • push
  • branch
  • head
  • tag
  • merge
  • conflict
  • diff
  • log
  • show
  • status

    2、Git工作空间和文件状态

    (1).工作空间

    常用的Git 知识点整理 - 图1
    左侧为工作区,右侧为版本库。

  • 工作区(Working Directory) 就是在电脑里能看到的目录,比如learngit文件夹就是一个工作区。

  • 版本库(Repository)工作区有一个隐藏目录.git,是Git的版本库。

在版本库中标记为index的区域为暂存区,标记为master的是Git自动创建的第一个分支,代表的是目录树。此时HEAD实际是指向master分支的一个“游标”,所以图示的命令中出现HEAD的地方可以用master来替换。图中的objects标识的区域为git的对象库,实际位于.git/objects目录下。

  • 当对工作区修改(或新增)的文件执行git add命令时,暂存区的目录树会被更新,同时工作区修改(或新增)的文件内容会被写入到对象库中的一个新的对象中,而该对象的id被记录在暂存区的文件索引中。
  • 当执行提交操作git commit时,暂存区的目录树会写到版本库(对象库)中,master分支会做相应的更新,即master最新指向的目录树就是提交时原暂存区的目录树。
  • 当执行git reset HEAD命令时,暂存区的目录树会被重写,会被master分支指向的目录树所替换,但是工作区不受影响。
  • 当执行git rm --cached命令时,会直接从暂存区删除文件,工作区则不做出改变。
  • 当执行git checkout .git checkout --命令时,会用暂存区全部的文件或指定的文件替换工作区的文件。这个操作很危险,会清楚工作区中未添加到暂存区的改动。
  • 当执行git checkout HEAD .git checkout HEAD命令时,会用HEAD指向的master分支中的全部或部分文件替换暂存区和工作区中的文件。这个命令也是极度危险的。因为不但会清楚工作区中未提交的改动,也会清楚暂存区中未提交的改动。

    (2).文件状态

    Git 有三种状态,文件可能处于其中之一:已提交(committed)、已修改(modified)和已暂存(staged)。

    3、Git配置系统级、全局、当前仓库用户名、邮箱的命令

    系统级、全局、当前仓库选项分别是:仓库-system-global-local(或默认不填)

    1. git config --global user.name "Fcant"
    2. git config --global user.email "fcscanf@outlook.com"

    列出Git设置

    1. git config --list
    2. git config -l

    4、Git fetch和pull的区别

  • git fetch:相当于是从远程获取最新版本到本地,不会自动merge.

  • git pull:相当于是从远程获取最新版本并merge到本地.

    (1). git fetch示例:

    Git fetch origin master

    1. git log -p master..origin/master
    2. git merge origin/master

    以上命令的含义:

  • 首先从远程的originmaster主分支下载最新的版本到origin/master分支上

  • 然后比较本地的master分支和origin/master分支的差别
  • 最后进行合并
  • 上述过程其实可以用以下更清晰的方式来进行:

    (2). git pull示例:

    1. git pull origin master

    上述命令其实相当于git fetchgit merge。在实际使用中,git fetch更安全一些,因为在merge前,可以查看更新情况,然后再决定是否合并。

    5、Git reset和revert的区别

  • git revert是用一次新的commit来回滚之前的commitgit reset是直接删除指定的commit

  • 在回滚这一操作上看,效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交,因此日后合并老的branch时,导致这部分改变不会再次出现,但是git reset是之间把某些commit在某个branch上删除,因而和老的branch再次merge时,这些被回滚的commit应该还会被引入。
  • git reset是把HEAD向后移动了一下,而git revert是HEAD继续前进,只是新的commit的内容和要revert的内容正好相反,能够抵消要被revert的内容。
  • git revertgit reset最大的不同是,git revert 仅仅是撤销某次提交。

另外,说一下git revertgit reset –hard–soft的区别

  • git reset –mixed id:是将git的HEAD变了(也就是提交记录变了),但文件并没有改变,(也就是working tree并没有改变)。
  • git reset –soft id:实际上,是git reset –mixed id后,又做了一次git add
  • git reset –herd id:是将git的HEAD变了,文件也变了。

    6、Git merge和reabse的相同点和不同点

    merge是合并的意思,rebase是复位基底的意思,相同点都是用来合并分支的。
    常用的Git 知识点整理 - 图2
    不同点:

  • merge操作会生成一个新的节点,之前的提交分开显示。而rebase操作不会生成新的节点,是将两个分支融合成一个线性的提交。

  • 解决冲突时。merge操作遇到冲突的时候,当前merge不能继续进行下去。手动修改冲突内容后,add 修改,commit就可以了。而rebase操作的话,会中断rebase,同时会提示去解决冲突。解决冲突后,将修改add后执行git rebase –continue继续操作,或者git rebase –skip忽略冲突。
  • git pullgit pull --rebase区别:git pull做了两个操作分别是”获取”和”合并”。所以加了rebase就是以rebase的方式进行合并分支,默认为merge。

总结:选择 merge 还是 rebase?

  • merge 是一个合并操作,会将两个分支的修改合并在一起,默认操作的情况下会提交合并中修改的内容
  • merge 的提交历史忠实地记录了实际发生过什么,关注点在真实的提交历史上面
  • rebase 并没有进行合并操作,只是提取了当前分支的修改,将其复制在了目标分支的最新提交后面
  • rebase 的提交历史反映了项目过程中发生了什么,关注点在开发过程上面
  • merge 与 rebase 都是非常强大的分支整合命令,没有优劣之分,使用哪一个应由项目和团队的开发需求决定
  • merge 和 rebase 还有很多强大的选项,可以使用 git help 查看

    7、Git stash是什么?它的相关使用方式命令

  • git stash:备份当前的工作区的内容,从最近的一次提交中读取相关内容,让工作区保证和上次提交的内容一致。同时,将当前的工作区内容保存到Git栈中。

  • git stash pop:从Git栈中读取最近一次保存的内容,恢复工作区的相关内容。由于可能存在多个Stash的内容,所以用栈来管理,pop会从最近的一个stash中读取内容并恢复。
  • git stash pop –index stash@{0}:恢复编号为0的进度的工作区和暂存区。
  • git stash apply stash@{1} 以将指定版本号为stash@{1}的工作取出来
  • git stash drop[] 删除某一个进度,默认删除最新进度
  • git stash list:显示Git栈内的所有备份,可以利用这个列表来决定从那个地方恢复。
  • git stash clear:清空Git栈。此时使用gitg等图形化工具会发现,原来stash的哪些节点都消失了 ```bash

    恢复工作进度

    git stash pop [—index] [] —index 参数:不仅恢复工作区,还恢复暂存区 指定恢复某一个具体进度。如果没有这个参数,默认恢复最新进度

这是git stash保存进度的完整命令形式

git stash [save message] [-k|—no-keep-index] [—patch] -k和—no-keep-index指定保存进度后,是否重置暂存区 —patch 会显示工作区和HEAD的差异,通过编辑差异文件,排除不需要保存的内容。和git add -p命令类似

  1. 使用save可以对进度添加备注
  2. ```bash
  3. # git stash save "这是保存的进度"

8、Git只从暂存区删除,从工作空间删除的命令分别是什么?

  1. git rm --cached
  2. git rm
  3. git commit

9、Git标签的使用

  1. # 列出现有的标签
  2. git tag
  3. # 打标签
  4. git tag -a v1.01 -m "Relase version 1.01"
  5. # 查看相应标签的版本信息
  6. git show v1.4
  • -a 选项,创建一个含附注类型的标签
  • -m 选项,指定了对应的标签说明

    9、Git分支的使用

    ```bash

    查看本地分支

    git branch

查看远程分支

git branch -r

创建本地分支(注意新分支创建后不会自动切换为当前分支)

git branch [name]

切换分支

git checkout [name]

创建新分支并立即切换到新分支

git checkout -b [name]

强制删除一个分支

git branch -D [name]

合并分支(将名称为[name]的分支与当前分支合并)

git merge [name]

查看各个分支最后提交信息

git br -v

查看已经被合并到当前分支的分支

git br —merged

查看尚未被合并到当前分支的分支

git br —no-merged

  1. <a name="yAJUQ"></a>
  2. ## 10、介绍Git冲突处理经验,以及`merge`和`rebase`中的ours和theirs的差别。
  3. merge和rebase对于ours和theirs的定义是完全相反的。在merge时,ours指代的是当前分支,theirs代表需要被合并的分支。而在rebase过程中,ours指向了修改参考分支,theirs却是当前分支。因为rebase 隐含了一个`git checkout upstream`的过程,将HEAD从local分支变成了upstream分支。git会在rebase结束后撤销这个改变,但它已经不可避免地影响了冲突的状态,使rebase中ours和theirs的定义与merge 截然相反。因此,在使用ours与theirs时请格外小心。
  4. <a name="vdrQr"></a>
  5. ## 11. Git远程操作相关
  6. <a name="sGMki"></a>
  7. ### (1). clone
  8. ```bash
  9. git clone <版本库的网址>
  10. git clone <版本库的网址> <本地目录名>
  11. # 克隆jQuery的版本库
  12. git clone https://github.com/jquery/jquery.git
  13. git clone -o jQuery https://github.com/jquery/jquery.git

(2). remote

  1. # 列出所有远程主机
  2. git remote
  3. # 使用-v选项,可以参看远程主机的网址
  4. git remote -v
  5. # 可以查看该主机的详细信息
  6. git remote show <主机名>
  7. # 添加远程主机
  8. git remote add <主机名> <网址>
  9. # 删除远程主机
  10. git remote rm <主机名>
  11. # 修改远程主机名称
  12. git remote rename <原主机名> <新主机名>

(3). fetch

  1. # 取回所有分支(branch)的更新到本地
  2. git fetch <远程主机名>
  3. # 取回某的特定分支的更新
  4. git fetch <远程主机名> <分支名>
  5. # 取回origin主机的master分支的更新
  6. git fetch origin master
  7. # 所取回的更新,在本地主机上要用”远程主机名/分支名”的形式读取。比如origin主机的master,就要用origin/master读取。可以使用git merge命令或者git rebase命令,在本地分支上合并远程分支
  8. git merge origin/master
  9. git rebase origin/master

(4). pull

  1. git pull <远程主机名> <远程分支名>:<本地分支名>
  2. # 取回origin主机的next分支,与本地的master分支合并
  3. git pull origin next:master
  4. # 如果远程分支是与当前分支合并,则冒号后面的部分可以省略。
  5. git pull origin next
  6. # 上面的命令实质上等同于先做git fetch,再做git merge。
  7. git fetch origin
  8. git merge origin/next
  9. # 合并需要采用rebase模式
  10. git pull --rebase <远程主机名> <远程分支名>:<本地分支名>

(5). push

  1. git push <远程主机名> <本地分支名>:<远程分支名>

注意:分支推送顺序的写法是“<来源地>:<目的地>”,所以git pull是“<远程分支>:<本地分支>”,而git push是“<本地分支>:<远程分支>”

  • 如果省略远程分支名,则表示将本地分支推送与之存在”追踪关系”的远程分支(通常两者同名),如果该远程分支不存在,则会被新建。
  • 如果省略本地分支名,则表示删除指定的远程分支,因为这等同于推送一个空的本地分支到远程分支。 ```bash

    将本地的master分支推送到origin主机的master分支。如果后者不存在,则会被新建

    git push origin master

省略了本地分支,以下等同,删除origin主机的master分支

git push origin :master git push origin —delete master

如果当前分支与远程分支之间存在追踪关系,则本地分支和远程分支都可以省略

git push origin

如果当前分支只有一个追踪分支,那么主机名都可以省略。

git push

如果当前分支与多个主机存在追踪关系,则可以使用-u选项指定一个默认主机,这样后面就可以不加任何参数使用git push

git push -u origin master

不管是否存在对应的远程分支,将本地的所有分支都推送到远程主机

git push —all origin

强制推送

git push —force origin

git push不会推送标签(tag),除非使用–tags选项

git push origin —tags

  1. <a name="hhquO"></a>
  2. ## 12、Git Flow使用简介
  3. 就像代码需要代码规范一样,代码管理同样需要一个清晰的流程和规范。三种广泛使用的工作流程:
  4. - Git flow
  5. - Github flow
  6. - Gitlab flow
  7. 三种工作流程,有一个共同点:都采用”功能驱动式开发”(Feature-driven development,简称FDD)。它指的是,需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该分支就合并到主分支,然后被删除。最早诞生、并得到广泛采用的一种工作流程,就是Git flow。<br />它最主要的特点有两个。首先,项目存在两个长期分支,分别是:主分支master、开发分支develop。其次,项目存在三种短期分支,分别是:功能分支(feature branch)、补丁分支(hotfix branch)、预发分支(release branch),一旦完成开发,它们就会被合并进develop或master,然后被删除。
  8. <a name="jn7fk"></a>
  9. ### (1). Git Flow流程图
  10. ![](https://cdn.nlark.com/yuque/0/2022/webp/396745/1642658395201-c2f7d7f4-7dba-42a9-a1a0-e79102fb075f.webp#clientId=u2eb0fc30-c29f-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u4818f789&margin=%5Bobject%20Object%5D&originHeight=678&originWidth=450&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=shadow&taskId=u73dbc7e9-1b80-41cb-aafe-eacade21c19&title=)
  11. <a name="iCrUs"></a>
  12. ### (2). Git Flow常用的分支
  13. - Production分支。也就是经常使用的Master分支,这个分支最近发布到生产环境的代码,最近发布的Release, 这个分支只能从其他分支合并,不能在这个分支直接修改。
  14. - Develop分支。这个分支是主开发分支,包含所有要发布到下一个Release的代码,这个主要合并与其他分支,比如Feature分支。
  15. - Feature分支。这个分支主要是用来开发一个新的功能,一旦开发完成,合并回Develop分支进入下一个Release。
  16. - Release分支。当需要一个发布一个新Release的时候,基于Develop分支创建一个Release分支,完成Release后,合并到Master和Develop分支。
  17. - Hotfix分支。当在Production发现新的Bug时候,需要创建一个Hotfix, 完成Hotfix后,合并回Master和Develop分支,所以Hotfix的改动会进入下一个Release。
  18. <a name="jJgHs"></a>
  19. ### (3). Git Flow代码示例
  20. <a name="j4v4Z"></a>
  21. #### a. 创建develop分支
  22. ```bash
  23. git branch develop
  24. git push -u origin develop

b. 开始新Feature开发

  1. git checkout -b some-feature develop
  2. # Optionally, push branch to origin:
  3. git push -u origin some-feature
  4. # 做一些改动
  5. git status
  6. git add some-file
  7. git commit

c. 完成Feature

  1. git pull origin develop
  2. git checkout develop
  3. git merge --no-ff some-feature
  4. git push origin develop
  5. git branch -d some-feature
  6. # If you pushed branch to origin:
  7. git push origin --delete some-feature

d. 开始Relase

  1. git checkout -b release-0.1.0 develop
  2. # Optional: Bump version number, commit
  3. # Prepare release, commit

e. 完成Release

  1. git checkout master
  2. git merge --no-ff release-0.1.0
  3. git push
  4. git checkout develop
  5. git merge --no-ff release-0.1.0
  6. git push
  7. git branch -d release-0.1.0
  8. # If you pushed branch to origin:
  9. git push origin --delete release-0.1.0
  10. git tag -a v0.1.0 master
  11. git push --tags

f. 开始Hotfix

  1. git checkout -b hotfix-0.1.1 master

g. 完成Hotfix

  1. git checkout master
  2. git merge --no-ff hotfix-0.1.1
  3. git push
  4. git checkout develop
  5. git merge --no-ff hotfix-0.1.1
  6. git push
  7. git branch -d hotfix-0.1.1
  8. git tag -a v0.1.1 master
  9. git push --tags