Git & JIRA & Confluence

gmf532196

2580人浏览 · 2021-04-07 16:30:06

gmf532196 · 2021-04-07 16:30:06 发布

TortoiseGit合并了分支后想撤消合并的方法，并在撤消合删除不想要的提交记录：

撤消合并： 首先，你需要撤消之前的合并操作。在 TortoiseGit 中，可以通过以下步骤来实现：
- 右键点击合并后的提交节点，选择 "Show log"。
- 在提交历史窗口中，右键点击合并提交，选择 "Revert changes by this commit"。
- 在弹出的对话框中，选择 "Revert commit" 并确认。
删除不想要的提交记录： 一旦合并被撤消，你可以删除不想要的提交记录。这可能需要使用 git reflog 命令来找到你想要删除的提交记录的哈希值，然后使用 git reset --hard <commit-hash> 来将分支重置到所需的提交上。git reset --hard [commit-hash] //就会删除commit-hash之后的提交记录。

TortoiseGit中拉取另外分支的某些提交，使用cherry-pick:

show-log ==> 选择需拉取的分支 ==> cherry-pick弹窗中选择某些提交。

一、Git:

git由于换了电脑key不一样，提交不了的，需要重新添加key和认证：
问题：Please make sure you have the correct access rights and the repository exists
解决办法：https://blog.csdn.net/qq_43705131/article/details/107965888

Git & Git-Flow :
1.workflow includes four phases: to do, in progress, code review, done

2.团队需要将大规模的项目分解成更小的任务，并在进展过程中响应需求或范围的变化，使用到的概念有：
　Stories : user stories(用户故事),是从最终用户的角度编写的简短需求或请求
Epics: 史诗(巨作),是可以分解为许多较小任务(称为故事)的大量工作
Initiatives : 倡议是Epics的集合，是为了驱动一个共同的目标
Themes : are labels that track high-level organizational goalsare(large focus areas that span the organization(跨越组织的大焦点领域)）

3.How to plan, track, and measure the incremental work: Scrum和kanban是团队训练敏捷方法的核心框架

在采用敏捷和DevOps时，史诗用于管理任务。它是定义的工作主体，根据客户或最终用户的需求/要求，将其划分为特定的任务（称为“故事”或“用户故事”）。

史诗是组织工作和创建层次结构的有用方法。想法是将工作分解为可交付的部分，以便大型项目可以实际完成，并且您可以继续定期向客户交付价值。史诗帮助团队分解工作，同时继续朝着更大的目标努力

在敏捷团队中，Story是团队可以在一个或两个星期的冲刺中完成的事情。通常，开发人员每个月会处理数十个Stories。相比之下，Epic的数量很少，而且需要更长的时间才能完成。团队通常每个季度要完成两三个Epics.

Gitflow实际上只是Git工作流程的抽象概念。这意味着它决定了要建立哪种分支以及如何将它们合并在一起

Feature分支使用Develop作为其父分支，Feature分支完成后merged into Develop分支，它永远不会与Ｍaster分支交互

Feature通常创建develop分支到最新分支：
创建功能分支(没有git-flow扩展名):
　　 git checkout develop
   git checkout -b feature_branch
使用git-flow扩展名:
git flow feature start feature_branch
完成功能分支开发后，合并到develop:
git checkout develop
   git merge feature_branch
使用git-flow扩展名:
   git flow feature finish feature_branch

git操作记录：

重装了系统后，git项目上操作可能会出现：
Could not get HEAD hash.
libgit2 returned: repository path 'D:/xxx/" is not owned by current user.
To add an exception for this directory, call:git config --global --add safe.directony ''
git config --global --add safe.directory "*"

使用短路径名：如果你在Windows系统上，可以尝试将Git的core.longpaths配置设置为true来允许更长的路径名。可以通过以下Git命令来设置：git config --system core.longpaths true

git推送本地新建的分支到远端：git push -u origin standalone

git checkout -b origin/bug/IDECD-2575_peter_memory_leak_fixes

git强制覆盖本地命令(单条执行):
　git fetch --all && git reset --hard origin/master && git pull

远程分支删除之后，本地还在，使用此命令试一下：
　　git remote prune origin

某个文件还原某个版本号：git checkout 3d2edd83e22szx /XX/xxx.cs

git clone 获取指定分支的指定commit-id版本：
第一步: git clone [git-url] -b [branch-name]
第二步: git reset --hard [commit-number]

git commit的三种方式： https://blog.csdn.net/chen930724/article/details/50174657
1. fast-forward : 默认的，快进方式，
2. squash : 把一些不必要

commit进行压缩，比如说，你的feature在开发的时候写的commit很乱，那么我们合并的时候不希望把这些历史commit带过来，于是使用--squash进行合并，此时文件已经同合并后一样了，但不移动HEAD，不提交。需要进行一次额外的commit来“总结”一下，然后完成最终的合并
3.--no-ff : 强行关闭fast-forward

git revert -m 1 cf26fc　　#执行撤消
//其中 -m 1 的意思是指定上图“合并提交”操作的10cc9a7ee 为主分支，抛弃197b28275
git reset -hard origin / master

git branch test
branch命令不会将我们带入分支，只是创建一个新分支。所以我们使用checkout命令来更改分支。

git checkout test //切换分支

git remote add origin 远端仓库地址
origin是远端仓库默认的别名，要求唯一性
git reset: head和分支名一起移动
git checkout :只移动head

git push origin --delete xxx //删除远端分支
git branch -r //查看远端分支情况
git checkout -b xx //创建并切换新的分支

//基于existing-branch-name创建一个新分支new-branch-name，同上？
git checkout -b new-branch-name existing-branch-name

添加分支注释：git config branch.[branchName].description '这是注释'
查看分支注释：git config branch.[branchName].description

git修改分支名：
1.修改本地分支名称：git branch -m oldBranchName newBranchName
2.将本地分支的远程分支删除：git push origin :oldBranchName
3.将改名后的本地分支推送到远程，并将本地分支与之关联：git push --set-upstream origin newBranchName

git拉取某一次提交的代码版本到本地分支
1.首先克隆分支，将代码拉下来：git clone https://xxxx/xxx.git
2.然后进行代码版本的拉取：git checkout -b branchName commit_ID

git将代码回退到某个commitID : git reset --hard commit-version
//commit-version可以通过git log --stat来查看所有历史commit的版本

当git推送不成功(如后退到某个提交点个修改后再提交)时，可考虑强制推送命令：
　 git push -f origin branch_name

sourcetree中的拉取和获取有什么区别
   “获取”的含义是命令git fetch，即从远程仓库抓取本地没有的修改；
   “拉取”的含义是git fetch + git merge，对应git中的命令git pull,即从远程仓库抓取本地没有的修改并自动合并到远程分支。
   由于git pull的结果有时会让我们看不懂，所以显式地使用fetch和merge命令会比较好一些。当然，对于一些简单的情况，前者git pull更方便一点。
　获取的用处更多的是用来查看对于你本地仓库的状态来说远程仓库是否有更新，并不会使你的本地仓库发生改变
　拉取会把你本地仓库没有而远程仓库有的更新写到你本地中，

git rebase和merge的区别：
　　rebase，合并的结果好看，一条线，但合并过程中出现冲突的话，比较麻烦rebase过程中，一个commit出现冲突，下一个commit也极有可能出现冲突，一次rebase可能要解决多次冲突；合并的历史脉络（冲突）被物理消灭了merge，合并结果不好看，一堆线交错，但合并有冲突的话，只要解一次就行了；
链接：https://www.zhihu.com/question/26492099/answer/730842005

Beyond Compare解决冲突：产生４个文件：

LOCAL	本地分支	当前所在分支
REMOTE	远程分支	要与当前分支合并的分支
BASE	共同祖先分支	要合并的两个分支的最近的共同祖先版本
BACKUP	冲突文件备份	冲突文件备份

git merge问题解决：当你在合并，但是突然不想要继续合并且丢弃了暂存区的所有东西，这时候还不能拉取或者其他操作，要先把指针恢复，使用命令：git reset --hard head

手动解决冲突：

Git GUI使用：
权限校验：首先,您的数据保存在远端服务器一份，服务器需要对您的身份识别。一段RSA加密字符串。
操作：
1.Step1-创建密钥: 启动Git GUI，菜单-帮助，Generate SSH KEY
2.Step2-添加密钥: 去你的代码托管服务器，你的账号设置中，添加它。//可用Home,company等作为标识来区别
账号保存, 如果不做设置的话，每次提交的时候，都会询问你填写密码。于是我们先来把这个设置好。
3.Step3.1-添加环境变量: 我的电脑 - 属性 - 高级系统设置 - 环境变量 - 新建变量

git add
git commit : 把此前add的文件(在stage中)，提交到Git(本地版本库)
git push : 上传到远端服务器
先来设置与远程地址的关联，Git remote：
在顶端菜单remote -> Add (add remote), add new remote:

git fetch
git merge

echo "# ooo" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/gmfxxx/ooo.git
git push -u origin master

//git graph图形解析：
git log --graph --decorate --oneline --all
　*表示一个commit，注意不要管*在哪一条主线上
　|表示分支前进
　/表示分叉
　\表示合入

常见操作：

1.合并到一半，冲突还没解决，还没提交，想撤销当前合并

git merge --abort

2.git撤销，放弃本地修改
2.1).对于还在工作区的代码(即未使用git add加入index缓存区代码)
git checkout . //放弃(本地)所有文件的修改
git checkout -- filePathName //放弃(本地)某个文件的修改; /*注：不写“--”就成了检出分支*/
2.2).对于已经使用了git add 缓存了代码：
git reset HEAD filePathName
git reset HEAD .
修改后相当于撤销git add命令所做的工作，本地的修改并不会消失，而是回到1的状态，继续用1中的操作，就可以放弃本地的修改
2.3).对于已经用git commit提交了代码：
git reset --hard HEAD^ ：回退到上一次commit的状态
git reset --hard commitid ：回退到任意版本

修改上一次commit的提交信息：

git commit --amend -m "New commit message"

这一步操作完之后要git pull一次, (应该还要git push)

3.git查看某个文件的修改历史：
cd 到文件所有的目录
git log --pretty=oneline File_Name.cs ####查询出来的是前面一大串是commitID
git show commitID File_Name.cs

4.clone版本库的某个分支: git clone -b branchA http://xxxxx/xxxx.git

放弃本地未添加的修改
git checkout -- 文件的相对路径

输入git mergetool, 就会自动调用YAMLMerge。自动修复场景和prefab文件冲突

git clone命令时出现错误fatal:unable to access 'https://github.comXXXXXXX":OpenSSL SSL_read:connection was errn. 解决方法：把https//换成 git://

.git文件太大的整理：
git verify-pack -v .git/objects/pack/pack-*.idx | sort -k 3 -g | tail -5

git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')"

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch ' vibot-u3d-PC-eBusiness.rar'" --prune-empty --tag-name-filter cat -- --all

删除存储的大文件
方法（1）：
#1.找出大文件的前5个
git verify-pack -v .git/objects/pack/pack-*.idx | sort -k 3 -g | tail -5
#2.找出大文件的文件名
git rev-list --objects --all | grep 8f10eff91bb6aa2de1f5d096ee2e1687b0eab007
#3.清除该文件的所有历史记录并强制刷新到所有分支(慎重,需要管理员权限,否则报错)
git filter-branch -f --prune-empty --index-filter 'git rm -rf --cached --ignore-unmatch <your-file-name>' --tag-name-filter cat -- --all
rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now
#4.强制更新远程仓库(这一步执行了，就真没救了。请确认已备份。)
git push --force --verbose --dry-run
git push --force

方法（2）：前提是知道要删除的大文件
#1.从提交历史中删除所有的zip文件
git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch *.zip' --prune-empty --tag-name-filter cat -- --all
#2.从提交历史中删除dist文件夹中的所有文件
git filter-branch --force --index-filter 'git rm -r --cached --ignore-unmatch uploads/' --prune-empty --tag-name-filter cat -- --all
#3.清除残余的 objects并通过GC回收空间
rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now
#4.强制更新远程仓库(这一步执行了，就真没救了。请确认已备份。)
git push --force --verbose --dry-run
git push --force

查看瘦身后的.git文件大小
du .git -lsh

submodules: .gitsubmodule文件

git submodule add ...(仓库B的地址）
git submodule add ...(仓库地址) src/B(你希望 submodule 位于的文件夹路径)

二、JIRA:

Epic Link分为: 空(无归属),IDECD Expert System,Vitural Enviroment(渲染相关的),Haptic Interface(硬件接囗), Haptic Device(硬件设备) //注:Epic Link其实就是属于哪个大的功能模块

story point是用来评估一个任务（Product Backlog）的难度，跟小时数没有必然的关系。Story point需要使用斐波那契数列来表示（1,2,3,5,8...）。只所以用这个序列是要更好的显示差异

1(天), 2(天), 3(天), 5(5天大概1个星期) ，8(大概半个月)

Jira中的面板说明:
Backlog：要做的，还没开始的需求(,而已完成了(状态是Done)的不会显示在面板上).

Jira中的概念: 参考敏捷Epic、Feature、Story和Task的关系 · 语雀

一个Feature可以分解成多个User Story, 一个User Story一般会分解为一个或多个Task.
Story和Task基本来说是同级的,但一般选Story,因为它有story points来更准确的来估算时间,Story下再分为SubTask.

Epic:可以理解为一个大版本。1.0，2.0，3.0之类的,规划的大模块，比如电商做了自营，接着做商家入驻
Feature：特性嘛，比如1.1，1.2，1.3。比如支付加了支付宝，登录支持扫码了。
Task：正在进行的需求

详细解析:

Feature:顾客提供价值的东西，它代表一个产品可以做什么，或提供什么服务;是可以满足用户的需求，为客户服务，为用户带来真正的价值的成果物的特性。它需要被分解成一个个更小的单位(就是下面讨论的User Story).
可由一组动宾结构的句子表达:
   扫描条形码
   · 显示单价
   · 计算总价
   · 计算税额
   · 打印清单

Minimal Marketable Feature (MMF)
User Story : 每个User Story不能单独被使用，而是一起构成一个Feature.
一个User Story必须是清晰的，可以为客户增加价值，而且更重要的是能够被估算。因此User Story通常是进行估算的基本单位(使用Story Point来进行估算)。User Story是在迭代的层级，一个User Story要在一个迭代内完成。
另外，User Story也是进行需求分析的工具。通过询问谁、做什么、为什么，能够简单明了地扑捉客户的需求。因此User Story通常写成以下形式：As a , I want , so than .
User Story的六大特点: User Story具有以下六大特点(INVEST)：
· Independent：独立的
   · Negotiable：可变的
   · Valuable：有价值的
   · Estimable：可估算的
   · Small：足够小的
   · Testable：可验收的/可测试的
使用User Story来跟踪开发进度更加准确。
//也可使用Task来跟踪开发进度，但Task的完成度有时不是那么容易清晰的定义或可视的，而User Story的完成度则是可视的
Task : 项目中可以执行的工作单位，通常就是迭代计划中项目(如Sprint Backlog中的项目)。一个User Story一般会分解为一个或多个Task，通过这些Task来实现。
如显示单价这个User Story，可以分解成：
   · 设计讨论会
   · 服务器查询单价编码
   · 服务器查询单价测试
   · 客户端显示单价编码
   · 客户端显示单价测试
Epic Story : Epic Story的规模和复杂性，要大于User Story，它首先是一个大User Story。由于它非常大，无法或不容易进行估算，因此一般会分解成为更小的User Story，进行估算和开发.
它与Feature同样是在Release Plan的层级，一般是通过一个或多个迭代才能完成.

Jira工作流的状态: TO DO(待办状态), IN PROGRESS(进行中,开发阶段),IN REVIEW(测试评审),DONE(完成); 当然工作流也可以自定义。

Jira Issue的状态(Status)说明:
状态说明了当前Issue的处理状态，默认为：TO DO （待定）。状态分为：TO DO（待定），Progressing（进行中），Resolved（已解决），Done（已完成），Reopen（重新打开），Pending(搁置)，Feedback（反馈）。

TO DO（待定）
每一个新建的Issue初始状态都为TO DO。

Progressing（进行中）
Issue（事件）指定给解决人之后，修改状态为Progressing，表示该Issue正在解决的过程中。

Resolved（已解决）
当解决人把指定的Issue解决完成后，修改状态为Resolved，表示该Issue已经解决完成，可以进行测试或验证了。

Done（已完成）
测试人员或验证人员（通常是PM），确认该Issue正确后，修改状态为Done，表示该Issue已经被验证完成，是一个合格的Issue。原则上，解决人不能够直接close指定给自己的Issue，必须由指定给自己的reporter来验证。

Reopen（重新打开）
验证不通过的Issue，修改状态为reopen，表示该问题仍未解决，可以指回给解决人继续解决。

Pending(搁置)
无法处理，暂时搁置的问题，修改状态为pending。

Feedback（反馈）
解决人对问题有疑问的问题，修改状态为Feedback，并指回给reporter。

软件缺陷的信息与跟踪流程
能够使用JIRA进程缺陷管理：JIRA的特点和使用者，JIRA的问题和工作流，JIRA的使用

软件缺陷的样例，
软件缺陷的基本内容：缺陷的标题、预置条件、重现步骤、实际结果、期望结果
软件缺陷的状态：新建(/激活)->打开->修复->关闭，还有拒绝
软件缺陷的严重程序：致(完全不能打开)、严(能打开，但主要的功能用不了)、一般(部分功能不能用)、建议(改进，可改可不改)
软件缺陷的优先级：主要是帮助开发人员明确工作的先后顺序，分为：低、中、高
//与严重程序有一定的相关性，但是与其是有差异的
//来开发组长或项目经理来最终定义
软件缺陷的类型：代码错误、设计缺陷、性能问题、安全相关

软件缺陷的跟踪流程：提交(测试人员)、确认(开发人员)、打开(开发人员)、修复(开发人员)、回归(测试人员)、关闭(测试人员)

JIRA----软件缺陷管理工具（还有类似的工具有：禅道、buggerfilar）
澳大利亚A
JIRA使用者：企业管理层、项目经理、测试人员、开发人员、其他人员

基本开发方法：问题类型：故障、任务、子任务、改进、新功能、Epic
JIRA中的问题(Issue)概念：可以是缺陷、新功能、新任务、改进等
JIRA中的工作流概念：工作的流动,问题的流转，其状态有： TO DO -> IN Progress -> IN Review(待评审) -> Done
//工作流在JIRA中也可自定义
JIRA的使用：测试提交->开发确认->开发修复->测试回归(验证)

//JIRA中有角色的概念：管理人员(admin), 测试、开发

Confluence: