拉取代码 创建分支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)) 一般表示还没搞定