git 开发和规范

Posted 2020-12-06 mofujin

git 常规

# 1.本地没有分支开发的情况

# 本地没有分支
# git checkout -b dev1
# 推送本地分支到远程仓库
# git push dev1 origin dev
||||或者
将远程git仓库里的指定分支拉取到本地（本地不存在的分支
git checkout -b 本地分支名 origin/远程分支名
# fatal: Cannot update paths and switch to branch ‘dev2‘ at the same time.
Did you intend to checkout ‘origin/dev2‘ which can not be resolved as commit?
# 执行：git fetch
# 在执行：
# 远程有本地的分支
# git clone/pull origin/远程分支 拉取指定分支
# git checkout -b 本地分支名 origin/远程分支名

# 2.提交

　　2.1

# 提交：
pull：是下拉代码，相等于将远程的代码下载到你本地，与你本地的代码合并

push：是推代码，将你的代码上传到远程的动作

完整的流程是：

第一种方法：（简单易懂）

1、git add .（后面有一个点，意思是将你本地所有修改了的文件添加到暂存区）

2、git commit -m""(引号里面是你的介绍，就是你的这次的提交是什么内容，便于你以后查看，这个是将索引的当前内容与描述更改的用户和日志消息一起存储在新的提交中)

3、git pull origin 远程分支名 这是下拉代码，将远程最新的代码先跟你本地的代码合并一下，如果确定远程没有更新，可以不用这个，最好是每次都执行以下，完成之后打开代码查看有没有冲突，并解决，如果有冲突解决完成以后再次执行1跟2的操作

4、git push origin master（git push origin 本地分支名:refs/remotes/远程分支名） 将代码推至远程就可以了

  　　2.2

第二种方法：

1、git stash （这是将本地代码回滚值至上一次提交的时候，就是没有你新改的代码）

2、git pull origin 远程分支名（将远程的拉下来）

3、git stash pop（将第一步回滚的代码释放出来，相等于将你修改的代码与下拉的代码合并）

然后解决冲突，你本地的代码将会是最新的代码

4、git add .

5、git commit -m ""

6、git push origin master（git push origin 本地分支名:refs/remotes/远程分支名）

这几步将代码推至了远程

最后再git pull origin 远程分支名 一下，确保远程的全部拉下来，有的你刚提交完有人又提交了，你再拉一下会避免比的不是最新的问题

# 3.拉取指定分支 并且本地之前已经拉过master 分支 说明 已存在 源 只是代码不一样而已

# 拉取指定分支：git fetch origin feat/notifier 不管在哪个分支都可以 拉取 
# 查看远程分支git branch -r 
# 查看本地分支git branch
# 在切换到哪个分支上进行开发：git checkout feat/notifier 

# 4.合并请求

　　1.1 线上请求Create new merge request dev1>>>develop 

　　1.2 git 操作

# 合并分支 比如：目前在feat/notifier 分支上 
 1.git add .
 2.git commit -m "feat:完成notify、email测试"
# 立马切换到你要合并到哪个分支上 :比如我要合并到develop分支上
# 1.git checkout develop 分支
# 2.git merge feat/notifier

# 在git commit -m "中的内容" 

其中，header 是必需的，body 和 footer 可以省略。
不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。

Header
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。

type
用于说明 commit 的类别，只允许使用下面7个标识。

feat：新功能（feature）

fix：修补bug

docs：文档（documentation）

style： 格式（不影响代码运行的变动）

refactor：重构（即不是新增功能，也不是修改bug的代码变动）

test：增加测试

chore：构建过程或辅助工具的变动

如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。

# 后续。。。。