git 常用命令

105 阅读4分钟

前景

此篇文章主要记录一下自己使用git操作时的知识,和平时工作中遇到的一些问题。分享一下,希望对于新入职场或者以前不怎么使用git的小伙伴有帮助。

指令


git add . // 将本地修改的代码添加到本地暂存区

git commit -m "代码备注" // 记录本次提交代码的功能信息

git push // 推送本地代码

git pull // 拉取远程代码

git status // 查看缓存区状态

git clone // 克隆代码仓库

git reset --hard [commit hash] // 回溯到 指定commit版本

git branch // 查看分支

git checkout // 切换分支

git merge // 合并分支

git tag // 标签

git remote // 设置远程仓库

以上是我日常工作时会用到的一些命令,下面呢我就单独细讲一下对应指令的详细操作

规范问题

关于分支

其实现在,大大小小的公司都有采用敏捷开发的模式,所以关于分支的管理是比较严格的。下面我简单的做了一个思维导图。

image.png

生产分支

上图中的main/master(也有可能是其它名字)表示的是生产分支,表示的是线上稳定版本的代码,这个分支是最重要的,一般代码合并到这个分支的时候是需要你得leader确认的。后面的tag表示的是标签,简单来讲就是做版本控制,比如说:tag:v1.0.0 、tag:v1.0.1等。

其次便是uat分支,他其实是一个模拟生产的分支,主要是用来给产品进行验收,通过验收后一般会收到一个验收报告,有了这个验收报告呢,你就可以把你得代码合到生产分支上,让相关的运维人员讲代码发布到正式的线上环境了

测试分支

不同的公司对应的测试环境或多或少,有的是一个,有的是多个,不同的测试分支部署到不同的地址中,提供给测试同事进行测试。

开发分支

开发分支主要就是和我们息息相关的环境了,这里面就会很多的分支。首先为什么分分支?

第一、方便管理(并行开发、功能隔离)。不同开发人员开发的代码是相互隔离的,多个分支的管理能够有效的减少代码冲突的出现次数

第二、版本控制。不同的需求版本可能在不同的时间上线,在你开发结束后,还需要测试->产品验收->上线(其中可能有bug打回重新走这个流程的细节就不多说了),在上线通告中只需要将可以上线的分支代码合并到生产分支上就可以了。

第三、实验性开发。在开发过程中,可能有代码走查,或者类似实验性优化等代码修改,创建一个实验性分支可以隔离掉,优化过程中出现的一些其它bug影响线上环境。

关于分支名

[开发类型]/[开发功能]/[上线日期]

开发类型: 这里有很多中,主要的就是:

  • 新功能:feature
  • 修复bug:fix
  • 优化:prefect
  • 其它:根据公司相关的规范制定

开发功能: 主要就是根据需求文档命名。 上线日期: 需求的确切上线日期,不是提测日期。

commit 提交规范

提交git commit -m "[提交类型]:[提交的内容说明]"的时候,对应的也有其规范要求。

提交类型:

  • feat: 新特征(新的功能)
  • fix: 修复某个bug
  • revert:回溯代码
  • docs:文档类型的跟新
  • style:代码风格的修改
  • pref:优化代码
  • test:测试用例
  • ...(其它还有蛮多、常用的基本就是这些)

命令说明


git push origin [本地分支]:[远程分支] // 如果不写本地分支,就是把当前分支推送到远程分支

git push --force // --force 主要是强行覆盖远程代码 缩写-f

git log // 查看提交记录

git branch -a // 查看所有分支信息,不加-a查看的是本地的分支

git checkout -b [分支名] // 切换分支 -b 的意思是分支不存在时候创建一个分支

git merge [合并分支名] 

git tag v1.0.0 // 给当前分支(一般是生产)做一个版本标识,注意!tag只是指向这个分支版本的地址,如果你删除了,tag的指向也就没了。

git push --force的使用场景:一般执行了版本回溯后(也就是git reset --hard [commit hash])我们提交代码(push)时候 git 会提示你 需要进行拉取(pull)操作,但是这个时候是不能执行的,如果你pull了,那你的代码就白回溯了,你需要把当前回溯的代码强行覆盖到远程上去


以上便是我工作时常用到的命令,欢迎其它小伙伴评论噢。