Git内容补充

1. Fast Forward模式

1.fast forward模式通常合并分支，如果可能，Git会用fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
禁用fast forward模式时，git会生成一个新的Commit，这样，从分支的历史上就可以看出分支信息

git checkout -b dev 
创建并切换到dev分支

修改 readme.txt 文件，并提交
git add readme.txt
git commit -m "add merge"

现在切回master
git checkout master

合并dev分支，这里使用禁止ff模式，ff：表示fast forward
git merge --no-ff -m "merge with no-ff" dev
因为本次合并要创建一个新的commit 所以加上-m参数，
把commit 描述写进去。合并后，
我们使用 git log 查看分支历史

结果如下：
$ git log --graph --pretty=oneline --abbrev-commit
* e1e9c68 (HEAD -> master) merge with no-ff
|\
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed
...

可看出，如果不使用ff模式，合并后就会变成这样：

使用ff模式图像是这样：

2. BUG分支

在软件开发中，bug就像是家常便饭，有bug就需要修复，在git中分支如此强大，所以，每一个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后临时分支删除掉

当你接到一个修复一个代号101的bug任务时，很自然，你想创建一个分支issue-101来修复它，但时，我们现在手头的工作还没有提交，但你不想提交，那就需要如下操作

2.1 前提

• 主分支：master
• 开发分支：dev
• 功能分支：feature
• 修补分支：issue-101
  开发人员在feature分支开发的过程中，需要中断开发开修改master分支中的Bug，修改完后回到feature分支继续工作，issue-101来源于master
  注意：feature 和issue-101都是临时性需要，使用完以后必须删除，是的代码库的常设分支始终只有master和dev分支

2.2 整体步骤

假设现在在feature分支工作

• 第一步：查看当前工作区有没有要提交的工作：git status
• 第二步：把当前工作现场储藏起来：git stash
• 第三步：查看当前状态：git status
• 第四步：切换到master分支修复BUG：git checkout master
• 第五步：创建并进入BUG修复分支：git checkout -b issue-101
• 第六步：修复并提交BUG ：git add readme.txt git commit -m "fix bug 101" <-- 4e93ac0b
• 第七步：查看当前工作状态：git status
• 第八步：切换到master分支：git checkout master
• 第九步：合并分支：git merge issue-101
• 第十步：删除issue-101分支：git branch -d issue-101
• 第十一步：查看当前的工作状态：git status
• 第十二步：回到feature分支继续工作：git checkout feature
• 第十三步：在feature上修复相同的BUG：git cherry-pick 4e93ac0b
  该命令可将bug提交到修改复制到当前分支，避免重复劳动
• 第十四步：查看当前的工作现场：git status
• 第十五步：恢复工作现场：git stash pop
• 第十六步：解决冲突（手动解决）

2.3 具体步骤：

(feature2)
1.$ git status
On branch feature2
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
        modified:   README.md

2.$ cat README.md
这是一个测试案例
这里完成了第一个功能
第二个功能进行中。。。

3.$ git stash
Saved working directory and index state WIP on feature2: 4e93ac0b 

4.$ cat README.md
这是一个测试案例
这里完成了第一个功能

5.$ git status
On branch feature2
nothing to commit, working tree clean

6.$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

(master)
7.$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean

8.$ git checkout -b issue-101
Switched to a new branch 'issue-101'

(issue-101)
9.$ cat README.md
这是一个测试案例
这里完成了第一个功能
为第一个功能改了一个BUG

10.$ git add README.md

11.$ git commit -m "fix bug 101"
[issue-101 307ca0e] fix bug 101
 1 file changed, 2 insertions(+), 1 deletion(-)

12.$ git status
On branch issue-101
nothing to commit, working tree clean

13.$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

(master)
14.$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean

15.$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 README.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

16.$ git branch -d issue-101
Deleted branch issue-101 (was 307ca0e).

17.$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)
nothing to commit, working tree clean

18.$ git checkout feature2
Switched to branch 'feature2'

(feature)
19.$ cat README.md
这是一个测试案例
这里完成了第一个功能

20.$ git cherry-pick 4e93ac0b
[feature2 8e74efd] fix bug 101
 Date: Tue Feb 23 14:51:00 2021 +0800
 1 file changed, 2 insertions(+), 1 deletion(-)

21.$ cat README.md
这是一个测试案例
这里完成了第一个功能
为第一个功能改了一个BUG

22..$ git status
On branch feature2
nothing to commit, working tree clean

23.$ git stash list
stash@{0}: WIP on feature2: ca1008f 

24.$ git stash pop
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
The stash entry is kept in case you need it again.

25.$ cat README.md
这是一个测试案例
这里完成了第一个功能
<<<<<<< Updated upstream
为第一个功能改了一个BUG
=======
第二个功能进行中。。。
>>>>>>> Stashed changes

3. 强制删除分支

我们一般都是在dev分支上工作，工作完成后切换到master分支与dev分支合并，但
就在我们的项目快要完成时，接到上级命令，因经费不足，新功能必须取消，虽然白干了，但这个包含机密的资料的分支就必须就地销毁：git branch -d dev销毁失败，根据提示该分支还没有被合并，如果删除将丢失掉修改，如果要强制删除，需使用-D参数即：

git branch -D dev

即可删除文档

4. 标签分支

能给分支的提交打上标签，一般是在master上打标签

4.1 打标签

git checkout master
切换进入master分支

git tag v1.0 == git tag -a v1.0
打上v1.0标签 默认是在最新的提交处

git tag v0.9 e1e9c68
在commitid为‘e1e9c68’的提交处打上标签
git tag -a v0.9 -m "version 0.9 released" e1e9c68
	-a：指定标签名 
	-m：指定说明文字
	
git tag 
查看标签列表

git show v0.9
查看标签信息

4.2 操作标签

• 如果标签打错了，也可以删除git tag -d v0.9

• 推送远程命令：git push origin v1.0

• 全部推送命令git push origin --tags

• 删除远程标签命令：
  git tag -d v0.9
git push origin :refs/tags/v0.9

5. 忽略特殊文件

在写Java文件时总是需要先编译在运行，这样会产生两个文件，即.class和.java我们在工作中
只需要一个.java的文件，为此需要使用Git上传时自动忽略.class文件
操作如下：

在工作区新建文件 .gitignore
打开该文件
输入 *.class

保存文件并提交
git add .
git commit -m "add gitignore file"

当再次编译运行时，查看工作状态时，只会发现.java文件