git 新入职员工流程

新入职员工工作流程

1.新进公司，先关联公司的代码仓库

git clone 仓库地址

我们可以和远程建立链接
将本地仓库和线上仓库建立关联：git remote add origin [线上仓库的SSH地址]

 如果在执行这句话的时候报错：fatal: remote origin already exists.

 那么就先执行 git remote rm origin

 再重新执行 git remote add origin [线上仓库的SSH地址]

设置git名字和邮箱

2. 设置自己的名字和邮箱，后面的提交代码，要有你的记录

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

git config user.name 查看是否配置

查看分支

3. 一般都是弄master分支的代码，先熟悉熟悉公司代码

我们可以查看当前所在分支 
git branch
可以查看远程分支和本地分支
git branch -a

开辟新分支

4. 有需求了，就要创建自己的工作分支了

如果领导让我们自己开一个新的分支
(
	git branch ask 创建一个工作分支
	git checkout ask 切换到新创建的工作分支
	此时，就可以在自己的工作分支，愉快的开发了
	
	开发完，就要提交代码了
	git add .
	git commit -m "feat: 提交内容"
	git push origin ask
	此时远程就多了一个分支ask
)


(
	拉取远程ask分支到本地ask分支，简写
	git pull origin ask
)

提交加推送到远程

git add .
git commit -m '注释'
git push origin ask //这一步，结合自己的实际情况可以忽略这一步
git checkout master
git merge ask
git push origin master

(如果此时报错还没建立远程链接，那我们先建立远程链接 
如果已经建立链接忽略此处)

git add

使用场景，你改了ABCD4个文件的代码，但是同事，要用你
文件A的代码，文件BCD改了一半，不能提交

添加一个或多个文件到暂存区：
git add [file1] [file2] ...
git add A(文件夹A) hello.php(文件夹B) 

添加指定目录到暂存区，包括子目录：
git add [dir]

我一般都是先 git status 找到改动的文件夹的目录
然后直接复制文件夹A的目录
git add 黏贴A目录
git commit -m "feat: 提交说明"
git push
就OK了，远程有A的修改了，BCD没有任何影响

暂存某个文件
git add --patch filename.x

git add -p 
允许交互式的选择你想要提交的部分

git log

git log master # 查看master分支的版本演变历史
git log --all --graph #以图形化的方式显示版本演变历史
git log -n2 #查看最近的两条记录
git log --oneline #简洁地显示版本演变历史

git checkout

git checkout 
会把当前没有提交的更改都带到，切换的分支

如果找不到，如果远程有同名分支啊，并且跟踪了---
git checkout -b  --track  / 

git checkout -b mybranch origin/abranch将创建mybranch和跟踪origin/abranch

git checkout --track origin/abranch将只创建' abranch'，
而不是具有不同名称的分支。

git checkout -B 
如果当前仓库中，已经存在一个跟你新建分支同名的分支，
那么使用普通的git checkout -b 这个命令，是会报错的，且同名分支无法创建。
如果使用-B参数，那么就可以强制创建新的分支，并会覆盖掉原来的分支。

rebase平滑合并

个人不建议rebase变基，忽略跳过这块内容
合并分支理解链接
rebase应该如何理解：re，重新；base，基础；rebase，
重新确定分支基础！
官网的变基链接
你的开发分支落后master分支的时候

切换到master分支，
	git checkout master
从master 啦最新的代码
	git pull
切换dev分支
	git checkout dev
移动dev分支到master的最后面
	git rebase master
切换回master,合并dev
	git checkout master
	git merge dev
推送到远程
	git push

变基rebase

git rebase master
(就好像，我从前几次的master变更，切出来的分支，
我又把我当前分支变到了，
master变更几次后最新的master切出来的分支一样)

	其实就是通过合并操作来整合分叉的历史
你可以提取在 C4 中引入的补丁和修改，然后在 C3 的基础上应用一次。
 	在 Git 中，这种操作就叫做 变基（rebase）
 你可以使用 rebase 命令将提交到某一分支上的
 	所有修改都移至另一分支上，就好像“重新播放”一样。
 	
 git checkout experiment
 git rebase master
 git checkout master
 git merge experiment

如果有冲突就不太好搞了

删除分支

假设我们的ask分支，完事了，不需要了
git push origin --delete ask
删除远程分支

git branch -d ask
删除本地分支

stash临时存储

git stash会把所有未提交的修改（包括暂存的和非暂存的）

都保存起来，用于后续恢复当前工作目录。

比如下面的中间状态，通过git stash命令推送一个新的储藏，

当前的工作目录就干净了。

适当的场景下使用的命令
当你在开发时，突然需要切换的别的分支
但是此时你还没开发完成
你不可以直接切换到别的分支
也不应该提交一个不完整的开发

临时存储就派上用场了

储藏工作 git stash
查看储藏列表 git stash list
（不常用）
应用最近的储藏 git stash apply
应用更早的储藏 git stash apply stash@{2}
删除储藏git stash drop stash@{0}
（比较常用的）
应用并删除储藏 git stash pop

存储多个时
直接git stash 
git stash list 存储的是{0} {1}
存储的多了，会忘记，存储的是什么

git stash push -m “<消息>”
可以给存储加提交消息，方便后面恢复，知道存储的是啥

git stash branch

如果你储藏了一些工作，暂时不去理会，
然后继续在你储藏工作的分支上工作

 git stash branch，这会创建一个新的分支，
 检出你储藏工作时的所处的提交
 重新应用你的工作，如果成功，将会丢弃储藏。

stash有个小坑

我有一次，做了一些修改，和添加了2张静态资源img
git stash后，修改正常存储，静态资源没有git add .跟踪
没有存储，切换别的分支把图片带过去了，这是错误的

默认情况下，git stash会缓存下列文件：
	添加到暂存区的修改（staged changes）
	Git跟踪的但并未添加到暂存区的修改（unstaged changes）

但不会缓存一下文件：
	在工作目录中新的文件（untracked files）
	被忽略的文件（ignored files）
git stash命令提供了参数用于缓存上面两种类型的文件。
使用-u或者--include-untracked可以没有跟踪的文件。
使用-a或者--all命令可以stash当前目录下的所有修改。

存储下来的会一直保留，确认没用了，可以清理掉
如果切换分支，带来了，不预期的改动，
我肯定不要别的分支改动，所以先临时存储
git stash show stash @ { 1 }
这样一层层的找，找到取出来，把
切换带来的改动清理掉

具体看下面链接的教程
https://opensource.com/article/21/4/git-stash

cherry-pick

 git cherry-pick命令的作用，就是将指定的提交
 （commit）应用于其他分支。
 其实就是只把提交的改动代码复制到另一个分支

git cherry-pick 

如果操作过程中发生代码冲突，Cherry pick 会停下来，
让用户决定如何继续操作。

具体如何解决，看阮一峰教程链接
点击链接

git reset和revert

原文链接

reset 版本回滚
	git reset --hard 06946e44(commit的哈希) or HEAD^
revert 
	我们commit了三个版本（版本一、版本二、 版本三），
	突然发现版本二不行（如：有bug），想要撤销版本二，但又不想影响撤销版本三的提交，
	就可以用 git revert 命令来反做版本二，生成新的版本四，
	这个版本四里会保留版本三的东西，但撤销了版本二的东西
	git revert -n 8b89621019c9adc6fc4d242cd41daeb13aeb9861
	git commit -m "revert add text.txt" 

git diff

忽略，我也没研究明白
如果想查看某个文件的改动
git checkout 文件路径
git diff

常见错误

最近在使用git的时候，git pull合并代码的时候，发生冲突。
最后返回一个MERGING状态。
(mian|master)
git reset --hard head

合并冲突报一大串看不懂的错
第一步 冒号 :
第二步
	大写Q可以退出
	mac 是 小写q
第三步
回车,确定

冲突

<<<<<<< HEAD

new new new new code

=======

old old old code

>>>>>>> xxxxxxxxxxxxxxxxxxxxxxx

分析：head 到 =======里面的lalala是自己的commit的内容

=========到 >>>>>>里面的hehehe是下拉的内容

根据需要删除代码就行了 完事把<<<<<<< ======= >>>>>>都删掉冲突就解决了


git pull就是先获取远端分支，然后将对应的远端分支merge到本地分支上来。
如果本地分支和远端分支已经分叉，则会在本地分支上产生一个新的提交。
如果有冲突，则需要手动解决冲突。

git reset

–hard 删除工作空间的改动代码，撤销commit且撤销add

(也就是说，彻底删了)

git log
查看要回滚的版本 commit id
git reset --hard  b498237e6dc1fc4861c79d3314d07285995b
或者
(git reset --hard HEAD^
HEAD指向的版本就是当前版本
^一个代表上一个,^^代表上2个版本)

强行提交
git push -f origin dev(远程分支名字)

远程覆盖本地，远程强行覆盖本地
git reset --hard origin/master

如果reset 是误操作
git reflog 可以找回你的commit
然后再重新 git reset --hard SHA1234

–soft 不删除工作空间的改动代码 ，撤销commit，不撤销git add file

(也就是说，保留你的改动)

git reset --soft HEAD^


--soft  
不删除工作空间改动代码，撤销commit，不撤销git add . 
注意，仅仅是撤回commit操作，您写的代码仍然保留。

--mixed 
意思是：不删除工作空间改动代码，撤销commit，并且撤销git add . 
这个为默认参数,

--hard
删除工作空间改动代码，撤销commit，撤销git add . 
注意完成这个操作后，就恢复到了上一次的commit状态。

git revert

git revert 撤销 某次操作，此次操作之前和之后的commit和history都会保留，
并且把这次撤销作为一次最新的提交
 git revert HEAD^   撤销前前一次 commit
 git revert commitid

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

reset只可以按顺序撤回commit
所以不按顺序的时候用revert

合并远程分支

git pull origin master:my_test
上面的命令是将origin厂库的master分
支拉取并合并到本地的my_test分支上。

git pull origin master
简写合并在当前分支

 git pull = git fetch + git merge FETCH_HEAD 
 git pull --rebase =  git fetch + git rebase FETCH_HEAD 


在master执行git merge test,然后会得到如下结果：

       D--------E
      /          \
 A---B---C---F----G---   test, master
 
 
在master执行git rebase test，然后得到如下结果：

A---B---D---E---C‘---F‘---   平滑合并

commit合并

首先，要了解为什么要合并commit提交，结合自己的
实际情况，考虑到底用不用合并commit
主要是commit有无用的提交。
造成分支污染，项目中充满了许多commit记录，
当出现紧急问题需要回滚代码时，就只能一条条的查看了。
代码review不方便，当你要做code review时，
一个很小的功能却提交了很多次，看起来就不是很方便了。

number代表合并几个
$ git rebase -i HEAD~2

这个是重点，可以直接编辑vi模式下的内容
注：vi 模式下，输入 i 进入编辑模式，输入完成后，
按下 esc，并且按下 冒号，输入 wq 进行保存。
此时，会跳转到之前 commit message 的编辑界面。
可以直接更改原来的，可以编辑提交说明文件
按下 esc，并且按下 冒号，输入 wq 进行保存。
看到 successfully 说明我们成功了，然后在输入 git log 看一下日志。


pick  使用提交
reword  修改提交说明
fixup  但丢弃提交说明日志
squash 融合到前一个提交
drop  删除提交，真的就删了你改的代码了

不理解可以看这里

# 命令:
# p, pick <提交> = 使用提交
# r, reword <提交> = 使用提交，但修改提交说明
# e, edit <提交> = 使用提交，进入 shell 以便进行提交修补
# s, squash <提交> = 使用提交，但融合到前一个提交
# f, fixup <提交> = 类似于 "squash"，但丢弃提交说明日志
# x, exec <命令> = 使用 shell 运行命令（此行剩余部分）
# b, break = 在此处停止（使用 'git rebase --continue' 继续变基）
# d, drop <提交> = 删除提交
# l, label  = 为当前 HEAD 打上标记
# t, reset  = 重置 HEAD 到该标记
# m, merge [-C  | -c ]  [# ]
# .       创建一个合并提交，并使用原始的合并提交说明（如果没有指定
# .       原始提交，使用注释部分的 oneline 作为提交说明）。使用
# .       -c <提交> 可以编辑提交说明。
#
# 可以对这些行重新排序，将从上至下执行。
#
# 如果您在这里删除一行，对应的提交将会丢失。
#
# 然而，如果您删除全部内容，变基操作将会终止。
#
# 注意空提交已被注释掉

如果觉得不够纤细，可以点我

查看是否和远程连接没问题

git remote -v

修改分支名称

git branch -m oldName newName
oldName 原始分支名
newName 当前分支名

git commit --amend

	如果commit注释写错了，只是想改一下注释，只需要：
	git commit --amend
	此时会进入默认vim编辑器，修改注释完毕后保存就好了
	i 进入编辑模式
	
	这样更快捷
	git commit --amend --only -m 'xxxxx'

	上一次提交忘记删除console，删除console之后又不想添加新的提交，
	但是第一次使用这个命令又有点懵，不知道该怎么操作....[]

	git commit --amend --no-edit 会保留上次的提交信息
	如果要修改上一条的message，那么去掉--no-edit选项即可
	并且最重要的是只有一条commit记录。

commit提交规范

 git checkout -b name 和 branch name git chekcout name 
 感觉不太一样，从单前检出单前分支，再拉一个别的分支，有冲突
 创建一个分支，再切换到单前分支

创建新分支，我tm老忘记规范，老挨叼
git checkout -b 名字为下面规范

feat/aa_bb_cc
fix/aa_bb
hotfix/aa_bb
bugfix/aa_bb
test/aa_bb

按照我这个格式就ok
git add .
git commit -m "feat 提交说明内容"

commit 类型
根据自己实际情况feat替换为下面的类型
	feat: 新特性
	fix: 修改问题
	refactor: 代码重构
	docs: 文档修改
	style: 代码格式修改, 注意不是 css 修改
	test: 测试用例修改
	chore: 其他修改, 比如构建流程, 依赖管理.
	pref: 性能提升的修改
	build: 对项目构建或者依赖的改动
	ci: CI 的修改
	revert: revert 前一个 commit

abort、continue、skip

这3个大佬，挺难搞的

git rebase --abort 会放弃合并
git rebase --skip 则会将引起冲突的commits丢弃掉（慎用！！）
git rebase --continue 合并冲突 然后再重新git add .

修改分支名称

git branch -m oldName newName

如果还有远程的

 删除远程分支
git push --delete origin oldName

 上传新命名的本地分支
git push origin newName

把修改后的本地分支与远程分支关联
git branch --set-upstream-to origin/newName

如果已经关联了远程分支，要先解除关联才可以
git branch --unset-upstream

对比分支

1. 显示出branch1和branch2中差异的部分
git diff branch1 branch2 --stat

2. 显示指定文件的详细差异
git diff branch1 branch2 具体文件路径

3. 显示出所有有差异的文件的详细差异
git diff branch1 branch2

4. 查看branch1分支有，而branch2中没有的log
git log branch1 ^branch2

5. 查看branch2中比branch1中多提交了哪些内容
git log branch1..branch2
注意，列出来的是两个点后边（此处即dev）多提交的内容。

6. 不知道谁提交的多谁提交的少，单纯想知道有什么不一样
git log branch1...branch2

7. 在上述情况下，在显示出每个提交是在哪个分支上
git log -lefg-right branch1...branch2
注意 commit 后面的箭头，根据我们在 –left-right branch1…branch2 的顺序，
左箭头 < 表示是 branch1 的，右箭头 > 表示是branch2的。

git revert 踩坑记录

1. 需要回滚的代码尽量reset
2. reset会把代码彻底删了找不到了
3. 除非远程还有没删之前的代码，（后悔了，可以重新拉下来）
4. revert用来回滚很多提交的某一个提交，会有revert记录
5. 一般用来，公司很多人上线，提交master上，
6. 你提交的代码夹在中间，用revert回滚
7. 注意⚠️，回滚过的代码，修改后再merge到master，是merge不上去的
8. （我自己merge后，没太注意，其实代码是merge不上去的，导致上线失败）
9. 此时用开发分支，rebase或者merge最新的master
10. 就有当时revert的记录， 再把revert的commit revert掉
11. 例如：  git revet bef7304357 (git revet -n bef7304357)
12. 不加-n revert完就完事了，加-n revert完，不进行提交，还需要重新提cooomit
13. 这样操作要注意，你revert是在最后执行的，会覆盖，
14. 你原来revert之后，修改的代码(如果2次修改在同一处)
15. 最优操作，从最新的master拉代码，先revert掉上一次的revert,
16. 再merge你的开发分支
17. 第二种方法不会留坑，
18. 两种方法的区别是，先revert再merge,还是先merge再revert,
19. 最后执行的操作，代码会覆盖先执行的操作


虽然，很长，或者不太理解
如果工作中遇到了revert后，又要merge上去，
可以创建新的test分支，按照自己理解多尝试几次

偶尔的BUG

git bug 很烦，应为一大串英文，看不懂，只能翻译加百度

1.bug
	you need to resolve your current index first
	merge失败，有conflicts没解决
	解决冲突后再次执行merge,我也不会
	回退到merge前执行 git reset --merge  

最后送上常见命令

分支操作常用命令

远程仓库操作