| Git

git一些常用操作

一、基础操作

1、初始化

git init

2、添加文件

git add . // 添加所有
git add README.md // 添加具体文件

3、注释

git commit -m "do something"

1
2
3
4
5
6
// 常用提交规范
<type>(<scope>): <subject> 

<body>

<footer>

type
1、feat：提交新的功能，feature。
2、fix：解决了 bug。
3、docs：修改的是文档相关的内容。
4、style：格式修改，没有修改代码逻辑。
5、refactor：重构代码，比如提取某段代码为一个方法、重构某个功能。
6、perf：性能、体验优化等，performance。
7、test：新增 test 用例或修改现有测试用例。
8、chore：非 src 和 test 的修改，比如构建流程, 依赖管理等。

scope
非必填，用于说明此次提交影响的范围，比如数据层、控制层、视图层等。

subject
必填，此次提交的简短描述。以动词小写开头，使用第一人称现在时，结尾不加标点。

body
非必填，可描述当前修改的行为详细信息或修改的目的。

页脚
非必填，以 BREAKING CHANGE 开头，后面是对变动的描述、以及变动理由和迁移方法。

4、添加远程仓库

// origin 远程仓库名称空格然后接具体地址
git remote add origin git@github.com:fenpho/kudzu-ui.git

5、推送代码

// 带上-u 参数其实就相当于记录了push到远端分支的默认值，这样当下次我们还想要继续push的这个远端分支的时候推送命令就可以简写成git push即可
git push -u origin master

二、分支操作

1、查看、新建、删除以及重命名分支

git branch //查看本地所有分支
git branch -r //查看远程所有分支
git branch -a //查看本地和远程的所有分支
git branch <branchname> //新建分支
git branch -d <branchname> //删除本地分支
git branch -d -r <branchname> //删除远程分支，删除后还需推送到服务器
git push origin:<branchname> //删除后推送至服务器
git branch -m <oldbranch> <newbranch> //重命名本地分支

tips: 重命名远程分支

  1. 删除远程待修改分支
  2. push本地新分支到远程服务器

git中一些选项解释

-d
–delete：删除
-D
–delete –force的快捷键
-f
–force：强制
-m
–move：移动或重命名
-M
–move –force的快捷键
-r
–remote：远程
-a
–all：所有

2、切换分支

切换分支
git checkout 分支名称
创建分支的同时，切换到该分支上
git checkout -b 新分支名称

3、从远程仓库pull（拉取）代码到本地分支

第一种方法：使用 git fetch（不用先在本地创建分支，是将远程主机的最新内容拉到本地，用户在检查了以后决定是否合并到当前分支中）

把远程分支拉到本地
git fetch origin dev（dev为远程仓库的分支名）
第一次拉分支最好不用添加任何参数
// 此命令会自动为你创建并拉取远程分支
git fetch

第二种方法：使用git pull（要在本地先创建相应的分支然后再拉取，将远程主机的最新内容拉下来后直接合并，即：git pull = git fetch + git merge，这样可能会产生冲突，需要手动解决）,以下方法二选一。

在本地创建分支dev并切换到该分支
git checkout -b dev(本地分支名称) origin/dev(远程分支名称)
把某个分支上的内容都拉取到本地
git checkout dev(分支名)
git pull origin dev(远程分支名称)

4、将新分支推送到远程仓库

git push 仓库名 分支名称
假设我本地创建了一个名为dev的分支，远程仓库为origin，且远程还没有这个分支，推送的命令是：
git push --set-upstream origin dev
分析：
git分支与远程主机存在对应分支，可能是单个可能是多个。

simple方式：如果当前分支只有一个追踪分支，那么git push origin到远程仓库时，可以省略分支名。

matching方式：如果当前分支与多个主机存在追踪关系，那么git push –set-upstream origin master（省略形式为：git push -u origin master）将本地的master分支推送到origin仓库（–set-upstream选项会指定一个默认分支），同时指定该仓库为默认仓库，后面使用可以不加任何参数使用git push。

注意：
Git 2.0版本之前，默认采用matching方法，现在改为默认采用simple方式。

5、删除分支

删除本地分支（不能删除当前所在的分支，如果要删除，必须先切换到其他分支上）
git branch -d 分支名称
如果删除时报错，可以使用 -D 强制删除，代码如下：
git branch -D 分支名称
删除远程分支, 注意：分支名称前有个冒号
git push origin :分支名称
分支名前的冒号代表删除或者使用–delete参数, 等价如下：
git push origin --delete 分支名称

6、合并分支

假如我们现在位于分支dev上，刚开发完自己负责的功能，执行了下列命令：
git add .
git commit -m '某某功能已完成，提交到[分支名称]分支'
git push origin dev
如果是多人开发的话，首先切换到master分支上
git checkout master
把远程master分支上的代码pull下来
git pull origin master
然后把dev分支的代码合并到master上
git merge master
如果git merge的时候出现冲突，处理冲突，推荐使用IDE工具处理
若是不想处理，直接使用远程的，可以执行下面的命令取消merge：
git merge --abort
然后记下本地修改，重置状态后，重新拉取远程代码合并后，添加上自己的代码
然后查看状态
git status
最后一步，Push推送到远程仓库
git push origin master

推荐的协作方式：
fork项目，通过merge request进行合并
首先fork项目到自己的名下
然后将合并后的代码推送到自己的仓库，发起合并请求到主仓库

知识点补充：

什么是分支【branch】？
1.Git 处理分支的方式可谓是难以置信的轻量，创建新分支这一操作几乎能在瞬间完成，并且在不同分支之间的切换操作也是一样便捷。 与许多其它版本控制系统不同，Git 鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次。 理解和精通这一特性，你便会意识到 Git 是如此的强大而又独特，并且从此真正改变你的开发方式。

2.Git保存的不是文件的变化或者差异，而是一系列不同时刻的快照 。在进行提交操作时，Git 会保存一个提交对象（commit object）。 该提交对象会包含一个指向暂存内容快照的指针，还包含了作者的姓名和邮箱，提交时输入的信息以及指向它的父对象的指针。 首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象， 而由多个分支合并产生的提交对象有多个父对象。

3.分支在实际开发中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样既安全，又不影响别人工作。

什么是派生【fork】？
派生的意思就是分岔/支流，gitblit上的派生，实际上就是git的分支，主支是master

三、修改提交记录

1、查看提交记录

git log
如果不带任何参数，它会列出所有历史记录，最近的排在最上方，显示提交对象的哈希值，作者、提交日期、和提交说明。如果记录过多，则按Page Up、Page Down、↓、↑来控制显示；按q退出历史记录列表。

-n 如果不想向上面那样全部显示，可以选择显示前N条。

2、修改

只修改提交信息

如果提交信息简单可以直接通过如下命令行完成:
git commit --amend -m "new commit message"

当需要为提交添加大量注释时，不添加参数，即直接使用git commit --amend进入vim编辑器编辑

vim编辑器:
pick：保留该commit（缩写:p）
reword：保留该commit，但我需要修改该commit的注释（缩写:r）
edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）
squash：将该commit和前一个commit合并（缩写:s）
fixup：将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f）
exec：执行shell命令（缩写:x）
drop：我要丢弃该commit（缩写:d）

只修改作者、邮箱
git commit --amend --author="Author Name <email@address.com>"

最后一次提交的话，直接根据需要运行上述命令就行，若是前边某次提交，看下边例子

1
2
3
4
5
6
7
8
9
10
11
12
例子：
// 如当前历史为 A-B-C(HEAD)，我想修改B和C，这两个commit的作者。
// 如果想改A则使用git rebase -i --root或者rebase到前面一次提交
git rebase -i A

// 按i，进入插入模式，将commit前的pick 改为 edit。按ESC，输入:wq。保存修改。
// 现在你已经开始可以修改，此时当前commit为B。
git commit --amend -m "new commit message" // 修改B的提交
git rebase --continue // 定位到C
git commit --amend --author="Author Name <email@address.com>" // 修改C的提交
git rebase --continue // 修改已完成。
git push -f // 提交代码，大功告成。-f为强制推送（会用本地覆盖远程，需慎重）

四、修改配置信息

当git全局设置的是公司的git的用户名和邮箱，但是在自己的github创建项目的时候，在提交的时候会出现公司的用户名和邮箱，这就需要进行一定配置

1、设置当前项目的git用户名和邮箱

设置用户名称
git config user.name "yourname"
设置用户邮箱
git config user.email "123456@qq.com"

2、设置全局的git用户名和邮箱

设置全局的用户名
git config --global user.name "youname"
设置全局的邮箱
git config --global user.email "123456@qq.com"

取消配置：git config --unset user.name，如果全局的化加上global参数即可

3、查看git全局的用户名称name和用户邮箱email可以使用以下方式

查看全局的用户名
git config --global user.name
查看全局的邮箱
git config --global user.email
查看git当前项目的用户名、邮箱，去掉global参数即可

4、git查看配置信息

config配置指令
git config
config 配置有system级别 global（用户级别） 和local（当前仓库）三个 设置先从system-》global-》local 底层配置会覆盖顶层配置 分别使用–system/global/local 可以定位到配置文件
查看系统级的配置信息
git config --system --list
查看用户级配置信息
git config --global --list
查看当前仓库配置信息
git config --local --list

五、贮藏

上版本master出现了bug，我们应该放下手头上新功能的开发工作先将master上的bug修复，这个时候dev分支下的改动怎么处理？ - 向dev分支提交新功能的代码，然后再切换到master下 - 直接切换到master分支下

首先我们新功能的代码还没开发完成，其次新功能这里还有一些bug没解决，就这样把有问题的代码提交到dev分支中，虽然可以解决目前我们的处境但不是很妥；但是第二种方案，直接切换，明显更不妥。怎么办？我们好像陷入了困境……

1、单次贮藏

别急，Git提供了一个git stash命令恰好可以完美解决该问题, 其将当前未提交的修改(即，工作区的修改和暂存区的修改)先暂时储藏起来，这样工作区干净了后，就可以切换切换到master分支下拉一个fix分支。在完成线上bug的修复工作后，重新切换到dev分支下通过git stash pop命令将之前储藏的修改取出来，继续进行新功能的开发工作
执行下述命令来储藏dev分支下的修改
git stash

然后执行git status
可以看到此时我们的工作区已经干净了，dev分支中被修改的文件也已经恢复到了版本库中的版本，说明dev分支修改已经被储藏成功了。这个时候我们就可以放心的切换到master分支下去修复我们线上版本的bug了。线上bug修复完成后，我们就可以继续开始之前的新功能的开发了

先切换到dev分支下:
git checkout dev

最后，取出之前储藏的修改
git stash pop

git stash pop可取出最近一次储藏的修改到工作区中，并同时将该储藏从储藏记录列表中删除

2、多次储藏

从上面的介绍，让我们对git stash命令有了一个基本的使用认知，其实，该命令可以将当前工作区的修改储藏来实现清空工作区。但是我们做了两次储藏(即，修改-储藏-再修改-再储藏)会发生什么呢？

查看储藏记录列表
git stash list

我们发现两次储藏记录的标识信息完全一致，只有其前面的index有别，这让我们很难确定我们所需取出的文件修改是储藏在哪一个中。在git默认按如下规则标识储藏记录(WIP意为work in progess, index用于后面取出所对应储藏的修改)，由于我们在dev分支下的两次修改中均未发生提交，所以其最近一次的提交ID是一致的。
stash@{index}: WIP on [分支名]: [最近一次的commitID] [最近一次的提交信息]

标识储藏记录
可以通过下述命令来标记此次储藏，以便后期查看
git stash save "stashMessage"

取出储藏
前文提到的可以通过git stash pop用于取出最近一次储藏的修改到工作区，而通过查看储藏列表的index的可以取出指定储藏中的修改到工作区

取出指定index的储藏的修改到工作区中
git stash apply stash@{index}
将指定index的储藏从储藏记录列表中删除
git stash drop stash@{index}