Git与Jira协同使用：提交与跟踪教程

注：

• [x] HEAD ： 指向最近一次commit里的所有snapshot（快照）
• [x] Index ：缓存区域，只有Index区域里的东西才可以被commit
• [x] Working Directory ： 用户操作区域
• [ ] Git的所有操作就是对这三个区域的状态（或内容）的操作；在进行git add / git commit 之后，就把 HEAD 的状态和 Index 以及 Working Directory 形成一致了

Git 的使用 & Code Review

1. 下载代码：git clone "xxx" -b xxxx
2. 更新代码：git pull /git fetch

• git pull 从远程仓库下载更新
• git fetch 从远程仓库下载数据库，不跟自己的仓库合并

3. 修改文件：通过pull更新代码之后进行修改代码文件 ，上传代码前一定要pull一下，再修改上传。
   1）git status ：修改完代码可以通过 git status 查看代码的修改点
   2）查看历史记录

• git log ：查看当前自己提交的历史记录； 空格向下翻页 / b 向上翻页 / q退出当前命令

git log filename   查看某个文件的commit记录
1.

git log -p filename     查看文件每次提交的diff (difference)
1.

git log --pretty=oneline filename 列出文件的所有改动历史
1.

git log --author=xxx  查看当前项目自己提交的历史记录
1.

• git reflog ：显示可引用的历史版本记录，it reflog命令中保留了从clone仓库开始，用户所有在本地库中的操作。

3）回退/重置到指定的提交（使用git reset --hard HEAD查看当前所在版本）回退都是在本地库移动HEAD指针（– soft参数，– mixed参数(默认方式)，–hard参数）

• git reset --hard 索引值 9f5868

索引值是前7位commit—id，
1.

• git reset --hard HEAD^ ：往后退一步()

一个^表示后退一步，n个表示后退n步；
(1) git reset --soft HEAD^  不删除工作空间改动代码，撤销commit，不撤销git add；
(2) git reset --mixed HEAD^ 和 git reset HEAD^ 效果一样。不删除工作空间改动代码，撤销commit，并且撤销git add；
(3) git reset --hard HEAD^  删除工作空间改动代码，撤销commit，撤销git add .注意完成这个操作后，就恢复到了上一次的commit状态
1.
2.
3.
4.

• git reset --hard HEAD~n ：后退

n：表示后退n步；
1.

• git reset --hard HEAD@{n}

n：表示回退n步；
HEAD@{n}与HEAD~n功能类似，但是HEAD~n回退的是git log命令显示的历史提交记录，而HEAD@{n}回退的是git reflog命令显示的历史提交记录。
1.
2.

• -- soft参数

仅仅在本地库移动HEAD指针

• -- mixed参数

在本地库移动HEAD指针 && 重置暂存区

• --hard参数

在本地库移动HEAD指针 && 重置暂存区 && 重置工作区

• git reset --mixed(默认) 带文件参数的git reset没有--hard, --soft这两个参数。只有--mixed参数

1. HEAD不会动
2. 将那个commit的snapshot里的那个文件放到Index区域中

4）git checkout : 切换分支，或者切换commit（并且会将所有HEAD和Commit 内容同步到工作区）

**注：**checkout是会修改 HEAD 的指向，变更 Index 区域里的内容，修改 Working Directory 里的内容。

• 当你checkout分支的时候，git做了这么三件事情

1. 将HEAD指向那个分支的最后一次commit
2. 将HEAD指向的commit里所有文件的snapshot替换掉Index区域里原来的内容
3. 将Index区域里的内容填充到Working Directory里

• reset --hard ，和 checkout 相比有两个重要的差别

4. reset --hard 会把 Working Directory 里的所有内容都覆盖掉；而 checkout 不会去修改你在Working Directory里修改过的文件
5. reset --hard 把 branch 移动到HEAD指向的地方；而 checkout 则把HEAD移动到另一个分支

• git checkout [branch] ：将HEAD 移动到branch 分支上(HEAD指向变了，file 文件内容未覆盖)

6. 更新了 index 区域里 file 文件的内容
7. 更新了 working directory 里 file 文件的内容

• 因此，使用 git checkout 时一般都是当前分支，这样就实现了git pull + 将当前add 内容保留到工作区

1. 按照时间搜索文件

• git log --since="2011-04-19" --until="2011-04-21"

2. 搜索某文件的修改记录，或某行的修改记录

• git log -p

按补丁格式显示 file 中每个更新之间的差异。
1.

• git blame -L <n, m>

查看一个文件，某些行的修改记录，某位软件编程人员的改动记录
1.

• git show 同第一个命令，也是查看difference

通过commitID，我们就可以查看我们想要的那个文件，包含我们需要查找的代码改动的记录了。
1.

• git log --pretty=oneline

1) 切换到要查看的文件所在的目录：
	cd softutil/littlefs/lfs_v1/src
2) 列出文件的所有改动历史，注意，这里着眼于具体的一个文件
	git log --pretty=oneline  <file> /**列出该文件的具体修改情况的commit_id*/
1.
2.
3.
4.

1. 将当前未提交的修改(即，工作区的修改和暂存区的修改)先暂时储藏起来

• git stash

git stash push temp.c  #储存单个文件，在需要进行git rebase的时候可以先将需要的文件储存，进行git pull，再还原处理
git stash -- temp.c temp1.c
git stash push -m "test" temp.c #储存并且添加标识说明

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

git stash list  # 查看储藏记录列表
1.
2.
3.
4.
5.
6.
7.
8.

• git stash show -p stash@{n} ：查看编号 stash{n} 的具体内容
• git stash apply stash@{n} ：将编号n的缓存释放出来，但是该缓存还存在于list中
• git stash pop ：取出最近的修改，并将缓存的内容释放掉（删除）
• git stash show ：查看所有的暂存点

git stash pop之后出现的：
Updated upstream 
    /**这里的内容就是pull下来的内容*/
=======
	/**这里的内容就是本地修改的内容*/
stashed changes
1.
2.
3.
4.
5.
6.

• 如果希望服务器上版本完全覆盖本地修改，使用如下命令回退并更新

git reset --hard
git pull
1.
2.

1. 提交代码流程
   1）git status ：查看目录下的修改点（仅显示统计信息, 而不显示具体的差异）
   （使用git diff 查看改写文件前后的差异）
   2）git checkout -- ：将不提交的文件恢复原样
   3）git stash ：将待提交的修改点暂存起来
   4）git pull origin <分支名> ：更新对应分支代码到最新
   5）git stash apply /(stash@{n}) ：将暂存的修改点 n 释放出来合并到对应代码文件中
   6）git add ：将目标文件提交到暂存区（index目录）git add . 加“."为提交所有文件
   7）git commit -m [message] ：将暂存区的文件提交到版本仓库，
   git commit，如果没有设置 -m 选项，Git 会尝试为你打开一个编辑器以填写提交信息。
   git commit --amend ：将上次提交的内容进行追加信息，或者查看当前提交内容（不修改）

-- (使用git commit之后，可以使用git show <commitID>查看修改的差异点)
|| (使用git diff HEAD -- <file1> <file2> 查看工作区与最新版本库之间的 指定文件名的文件差异) //HEAD 也可以换成具体某一个版本，必须在没有commit之前记得修改“\”为“/”
1.
2.

8）git push

git push xxx ：将文件提交到远程的项目文件下

git push origin HEAD:refs/for/Branch_Name ：将提交内容同步到远程仓库的分支名下

9）进入gerrit 检查修改点，进入case提交修改状态，然后进入gerrit添加Reviewers, 校验码+1，+1，然后点击reply发送。等待回复合并

1. 解决冲突

• (1) 出现 cannot Merge 的时候代表出现了冲突

• 提交完代码之后出现冲突，【此时大家都提交了代码不能进行合并】未使用git pull就进行了提交git push
  1）git pull 代码地址 分支 --rebase 将会出现Merge（n）n代表冲突点
  2）拉取流程中断，需解决冲突
  3）解决冲突，将对应的代码与自己不同的进行修改，修改过的就改成它的模样，没有修改到的就改成自己的样子，最后将该文件add到暂存区：git add filename
  4）将拉取过程继续 ： git rebase --continue
  5）将暂存区的修改追加到上一次commit：git commit --amend
  6）再次提交代码：git push origin HEAD:refs/for/Branch_Name
• 提交代码的时候出现冲突（MERGING）【此时远程代码和自己工作区修改之前的代码不同】在提交git push 之前使用git pull出现的问题
  1）git pull 代码地址 分支 会出现“head >>>> ===== ”这种，就可以进行解决冲突了，保存需要的代码，删除不需要的和 “head >>>> ===== ”
  2）git add file ，再先将修改的文件提交到暂存区
  3）git reset --hard commitID ，将版本重置到冲突之前的提交，在进行commit和push

• (2) 使用 vscode 解决上传合并中的冲突

• 解决冲突的方法： 1）git pull 拉到最新代码先把有冲突的代码拉下来 2）修改冲突，通过 git status 查看冲突的文件，然后进行修改， 3）修改完成之后，把那个文件 git add 冲突文件 4）git cherry-pick --continue 5）git push origin HEAD:refs/for/分支 重新上库

• (3) 出现$ git commit please add [RequestType][TestType][Topic]: in msg 冲突MERGING

• 1）出现该merging的原因是git commit之后没有输入提交文本，
  2）再次使用 git commit --amend 然后输入提交文本，
  3）这样就把commit的内容提交到版本库之中（只是没有push到远程仓库），
  4）最后使用 git log ，然后使用 git reset --hard commitID 退回到上个 commit 之中

# 先处理完C，会继续报D的冲突，所以下面命令一共会执行两次
git add file
git rebase --continue #改变基底
1.
2.
3.

1. 使用git cherry-pick （合并其他人的修改或者自己提交的修改）
   git fetch "ssh://y0304@10.238.1.10:29418/ASR/ASR1603" refs/changes/70/14470/1 && git cherry-pick FETCH_HEAD

使用该代码进行cherry pick之后可以在本地代码之中合入下载的当前分支的代码，然后自动进行代码合入，如果有冲突则进行手动解决，然后手动git add 冲突文件；否则则会自动进行git add，自己只需要进行git push操作就行，如何还有代码需要修改，也可以修改之后进行git add 修改文件，然后git commit --amend，添加需要修改的文件内容，即可进行提交操作。

• 修改编辑器
  git config --global core.editor "D:\Notepad++\notepad++.exe"-multiInst –n 修改为具体的编辑器路径
• 删除文件
  rm
• 显示分支名称
  git branch

使用git进行patch补丁

1. 使用commitID的方式

• [x] 生成patch
• 首先先通过git log 查看有哪一些commit
• 把第一次commit 提交以后的（不包括第一次提交）都生成patch
  命令：**git format-patch **
  注：某次提交（含）之前的几次提交：
  git format-patch –n --n指patch数，07fe对应提交的名称 故，单次提交即为：
  git format-patch -1
• [x] 打入patch
• git am --abort
• git am \.patch （.patch代表当前路径下的所有patch文件，可以添加单个文件或者某一路径下的某些文件）

2. 使用单个文件的方式（不推荐就不写了）

• git format-patch 命令：

$ git format-patch HEAD^ 　  #生成最近的1次commit的patch

$ git format-patch HEAD^^　　#生成最近的2次commit的patch

$ git format-patch HEAD^^^ 　#生成最近的3次commit的patch

$ git format-patch HEAD^^^^  #生成最近的4次commit的patch

$ git format-patch <r1>..<r2>   #生成两个commit间的修改的patch（包含两个commit. <r1>和<r2>都是具体的commit号)
$ git format-patch -1 <r1>   #生成单个commit的patch

$ git format-patch <r1>      #生成某commit以来的修改patch（不包含该commit）

$ git format-patch --root <r1>　#生成从根到r1提交的所有patch
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

• git am命令：

$ git apply --stat 0001-limit-log-function.patch   # 查看patch的情况

$ git apply --check 0001-limit-log-function.patch  # 检查patch是否能够打上，如果没有任何输出，则说明无冲突，可以打上
(注：git apply是另外一种打patch的命令，其与git am的区别是，git apply并不会将commit message等打上去，打完patch后需要重新git add和git commit，而git am会直接将patch的所有信息打上去，而且不用重新git add和git commit,author也是patch的author而不是打patch的人)

$ git am 0001-limit-log-function.patch  
	# 将名字为0001-limit-log-function.patch的patch打上
$ git am --signoff 0001-limit-log-function.patch 
	# 添加-s或者--signoff，还可以把自己的名字添加为signed off by信息，作用是注明打patch的人是谁，因为有时打patch的人并不是patch的作者
$ git am ~/patch-set/*.patch　
	# 将路径~/patch-set/*.patch 按照先后顺序打上
$ git am --abort                                                     	 # 当git am失败时，用以将已经在am过程中打上的patch废弃掉(比如有三个patch，打到第三个patch时有冲突，那么这条命令会把打上的前两个patch丢弃掉，返回没有打patch的状态)
$ git am --resolved                                                   	  #当git am失败，解决完冲突后，这条命令会接着打patch
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.