拉取代码 创建分支 git branch dev git checkout -b dev git switch -c dev
切换本地分支 git checkout dev git switch dev
切换分支并关联远程分支 git checkout -b dev origin/dev git checkout --track origin/dev
查看本地所有分支 查看远程所有分支 删除本地分支 删除远程分支 将代码从工作区添加暂存区 查看尚未暂存的更新 添加提交信息(commit
注释写错,执行 git commit --amend
此时会进入默认 vim
编辑器,修改注释后保存) 推送代码到远程分支 git push origin dev git push -f origin dev
拉取远程分支代码 合并分支 查看 git
状态 查看提交历史 查看可引用的历史版本记录 把本地未 push
的分叉提交历史整理成直线 回到 rebase
执行之前的状态 回退版本 git reset --hard commit_id git reset --soft HEAD^ git reset --soft HEAD~1
撤销代码 修改分支名 git branch -m oldBranchName newBranchName git push origin :oldBranchName git push --set-upstream origin newBranchName
查看 git
配置 git config --global --list git config --global user.name
添加用户名 git config --global --add user.name newName
删除用户名 git config --global --unset user.name
修改用户名 git config --global user.name newName
配置 Git
用户名和邮箱 git config --global user.name "Your Name" git config --global user.email "email@example.com"
统计代码行数 git ls-files | xargs wc -l
分支管理规范化 - Git Flow 分支管理策略 分支命名规范 master 分支:master 分支只有一个,名称即为 master 。GitHub 现在叫 main
develop 分支:develop 分支只有一个,名称即为 develop
feature 分支:feature/<功能名>,例如:feature/login,以便其他人可以看到你的工作
hotfix 分支:hotfix/日期,例如:hotfix/0104
分支说明 master || main 分支:存储正式发布的产品,master || main 分支上的产品要求随时处于可部署状态。master || main 分支只能通过与其他分支合并来更新内容,禁止直接在 master || main 分支进行修改。
develop 分支:汇总开发者完成的工作成果,develop 分支上的产品可以是缺失功能模块的半成品,但是已有的功能模块不能是半成品。develop 分支只能通过与其他分支合并来更新内容,禁止直接在 develop 分支进行修改。
feature 分支:当要开发新功能时,从 master 分支创建一个新的 feature 分支,并在 feature 分支上进行开发。开发完成后,需要将该 feature 分支合并到 develop 分支,最后删除该 feature 分支。
release 分支:当 develop 分支上的项目准备发布时,从 develop 分支上创建一个新的 release 分支,新建的 release 分支只能进行质量测试、bug 修复、文档生成等面向发布的任务,不能再添加功能。这一系列发布任务完成后,需要将 release 分支合并到 master 分支上,并根据版本号为 master 分支添加 tag,然后将 release 分支创建以来的修改合并回 develop 分支,最后删除 release 分支。
hotfix 分支:当 master 分支中的产品出现需要立即修复的 bug 时,从 master 分支上创建一个新的 hotfix 分支,并在 hotfix 分支上进行 BUG 修复。修复完成后,需要将 hotfix 分支合并到 master 分支和 develop 分支,并为 master 分支添加新的版本号 tag,最后删除 hotfix 分支。
提交规范 相关参考
提交信息应该描述“做了什么”和“这么做的原因”,必要时还可以加上“造成的影响”,主要由 3 个部分组成:Header、Body 和 Footer。
Header Header 部分只有 1 行,格式为<type>(<scope>): <subject>
。
type 用于说明提交的类型,共有 8 个候选值: feat:新功能( feature ) fix:问题修复 docs:文档 style:调整格式(不影响代码运行) refactor:重构 test:增加测试 chore:构建过程或辅助工具的变动 revert:撤销以前的提交 scope 用于说明提交的影响范围,内容根据具体项目而定。 subject 用于概括提交内容。 CodeReview
常用缩写PR
(Pull Request)拉取请求,给其他项目提交代码LGTM
(Looks Good To Me)代码已经过 review,可以合并SGTM
(Sounds Good To Me)和上面那句意思差不多,也是已经通过了 review 的意思WIP
(Work In Progress)如果有个改动很大的 PR,可以在写了一部分的情况下先提交,但需在标题写上 WIP,以告诉项目维护者这个功能还未完成,方便维护者提前 review 部分提交的代码PTAL
(Please Take A Look)提示别人来看一下TBR
(To Be Reviewed)提示维护者进行 reviewTL;DR
(Too Long; Didn’t Read)太长懒得看TBD
(To Be Done(or Defined/Discussed/Decided/Determined)) 一般表示还没搞定