精华内容
下载资源
问答
  • git规范
    2020-11-22 18:08:54

    分支

    初始的仓库为master,开发人员从master仓库创建自己的开发分支进行开发,功能开发完成后推行远程,测试确认需要提测后再合并到测试分支,进行打包测试,测试通过由一个负责管理仓库的人将开发分支代码合并到灰度打包发布进行灰度体验测试,灰度未发现问题,将开发分支合并到master仓库进行打包上线。
    

    git clone 指定的单个目录或文件夹

    基于sparse clone变通方法

    • 创建一个空仓库
    • 拉取远程仓库信息
    • 开启 sparse clone
    • 设置过滤
    • 更新仓库

    创建空仓库

    mkdir devops
    cd devops
    git init  # 初始化
    

    拉取远程仓库信息

    git remote add -f origin http://your/git/repo.git  # 拉取远程仓库信息
    

    开启 sparse clone

    git config core.sparsecheckout true  # 开启 sparse clone
    

    设置过滤

    echo "test" >> .git/info/sparse-checkout  # 设置过滤条件
    

    更新仓库

    git pull origin master # 拉取仓库
    

    master仓库

    主线分支,主要存放生产环境代码以及负责灰度,测试,开发分支的创建

    gray分支

    灰度分支,代码版本领先与主线分支,落后与测试分支,数据和主线分支基本保持一致,进一步完善测试所遗漏的细节问题。

    test分支

    测试分支,主要为测试人员提供使用,验证开发人员开发的新功能。

    dev分支

    开发分支,用于合并多人分支代码集成到统一环境

    强推

    开发过程中尽量不要使用强推

    git常用指令

    创建分支

    • git branch test git基于当前commit创建test分支, .git/HEAD 文件中记录了当前分支名字

    切换分支

    • git checkout test 从当前分支切换到test分支

    创建并切换新分支

    • git checkout -b test git基于当前commit创建test分支并且切换到test分支

    合并其他分支

    • git merge origin master 将origin mergemaster
    • git merge origin/master 将origin上的master分支 merge 到当前 branch 上

    删除分支

    • git branch -d test 删除本地test分支
    • git branch -D test test分支还没有合入当前分支,所以要用-D参数才能删掉。
    • git push origin --delete test 删除远程test分支
    • git push origin :test 删除远程test分支

    查看当前分支

    • git branch 列出当前分支清单
    • git branch -a 查看远程分支和本地分支
    • git branch -v 查看各个分支最后一个提交信息
    • git branch --merged 查看哪些分支已经合并入当前分支

    拉取分支

    • git remote update 更新远程分支列表
    • git checkout -t remotes/origin/test 切换远程分支到本地
    • git pull origin test 拉取远程分支代码到本地

    代码回滚

    • git log 查看提交记录
    • git reset --hard commit_id 回滚到某一版本,–hard – 强制将缓存区和工作目录都同步到你指定的提交
    • 提交到远程覆盖

    同步本地与远端同一分支提交历史

    • git rebase
    • git pull --rebase 与上面效果的指令一样
    更多相关内容
  • 这个插件就是规范git提交规范,让你的提交不仅"好看"还"实用" git 规范提交从何说起? git 规范提交从哪里开始的呢?起源在哪呢?emmmmmm,这就追溯到了Angular了! 让我们看下Angular社区的提交规范 这个提交记录是不是...
  • Git规范

    千次阅读 2021-07-16 14:09:23
    六、Git规范 1、分支管理 master 主分支:master主分支始终保持稳定的可发布版本 说明:只有项目组主程才拥有master主分支的管理权限(例如其他分支合并到master必须由主程操作) dev 开发分支:dev开发分支为不...

    六、Git规范

    1、分支管理

    1. master 主分支:master主分支始终保持稳定的可发布版本
      • 说明:只有项目组主程才拥有master主分支的管理权限(例如其他分支合并到master必须由主程操作)
    2. dev 开发分支:dev开发分支为不稳定版本,可能存在功能缺失,但已有的功能必须是完整的
      • 说明:原则上不允许直接在dev分支上进行功能开发,必须新建feature分支进行开发
    3. hotfix-[问题名称 | bug编号] 紧急热修复分支:从master分支创建,横线后面跟上问题名称或者对应的bug编号,仅仅适用于生产线问题紧急修复
      • 说明:修复完成,测试通过,合并到master和dev分支上,然后将此分支删除
    4. feature-[功能名称] 功能开发分支:从dev分支创建,横线后跟功能名称,用于新功能开发,每天下班前push提交到远程
      • 说明:开发完成以后,在远程发起向dev分支的合并请求,由指定的CodeReview人员审查通过以后进行合并,并删除该分支
    5. bugfix-[bug编号] 问题修复分支:从dev分支创建,用于修改测试提出的bug,横线后跟bug编号
      • 说明:修复以后,在远程发起向dev分支的合并请求,并指定提交者自身(或其他人)作为CodeReview,合并以后删除该分支
    6. refactor-[重构名称] 重构分支:从dev分支创建,用于代码的重大规模重构(小规模重构创建feature分支即可)
      • 说明:重构以后,必须经过严格测试通过,才能向dev分支合并。

    2、Commit提交规约

    1. 提交信息格式:

      <type>(<scope>): <subject> #header
      // 空一行
      <body>
      // 空一行
      <footer> 
      
      • 说明:
        • Header部分只有一行,包括三个字段:type(必需)、scope(可选)和subject(必需)。<body>和<footer>可省略
        • type用户说明本次commit类型,只允许使用下面7个标识:
          1. feat:新功能(feature)
          2. fix:修补bug
          3. docs:文档(documentation)
          4. style: 格式(不影响代码运行的变动)
          5. refactor:重构(即不是新增功能,也不是修改bug的代码变动)
          6. test:增加测试
          7. chore:构建过程或辅助工具的变动
        • scope:用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。
        • subject:是 commit 目的的简短描述,不超过50个字符。
    2. commit提交频率

      • 每天下班前必须提交分支,并push到远程。
      • hotfix、feature、bugfix、refactor分支尽量按照功能点或修复重构的问题及时commit(不要求push)

    3、git操作规范

    4、重点注意事项

    • 在团队开发中,git的操作流程应至少遵循如下步骤(重点)

      • commit 本地代码到本地库(防止出现问题时,可以回调)
      • pull 远程库的代码
      • push 本地库代码到远程看
    • 在合并分支流程,如:分支1的代码需同步到分支2上

      • 先切换到需要同步代码的分支2
        • image-20210813134557924
        • image-20210813134823596
      • 点击需要同步过来的分支1,点击merge into current
        • image-20210813134936844
    • 如果pull代码过程中,merge出错的处理方式

      • 通过 git reflog [分支名] 的命令查看响应的日志
        • image-20210813135348250
      • 获得上一次 commit_id 如上:afe54ca,然后通过 git reset --hard commit_id,例如:git reset --hard afe54ca
        • image-20210813135557074
      • 再通过pull 命令拉取最新的代码,再重新合并即可
    • 重点注意

      • 每次 pull 前,切记要提交本地代码到本地库中,否则可能回出现合并代码出错,导致代码丢失的情况
    展开全文
  • 代码规范、git规范、teambition规范、yii规范 1. 命名规范 (1).变量命名规范 1.变量使用驼峰命名法 禁止使用拼音或者拼音加数字 2.变量也应具有描述性,杜绝一切拼音、或拼音英文混杂的命名方式 3.变量包数字、...
  • git规范细则

    2020-09-16 21:04:48
    git规范细则

    git规范细则


    对于Git的提交日志,我们有非常明确而详细的提交规范。这将有助于我们在查看 项目历史时, 更容易明确每一次提交的内容。

    提交消息格式

    每个提交消息都由一个标题、一个正文和一个页脚组成。而标题又具有特殊格式,包括修改类型、影响范围和内容主题:

    修改类型(影响范围): 标题
    <--空行-->
    [正文]
    <--空行-->
    [页脚]
    

    标题是强制性的,但标题的范围是可选的

    提交消息的任何一行都不能超过100个字符!这是为了让消息在GitHub以及各种Git工具中都更容易阅读。

    修改类型

    每个类型值都表示了不同的含义,类型值必须是以下的其中一个:

    • feat: 提交新功能
    • fix:修复了bug
    • docs:只修改了文档
    • style:调整代码格式,未修改代码逻辑(比如修改空格、格式化、缺少分号等)
    • refactor:代码重构,既没修复bug也没有添加新功能
    • perf:性能优化,提高性能的代码更改
    • test:添加或修改代码测试
    • chore:对构建流程或辅助工具和依赖库(如文档生成等)的更改

    代码回滚

    代码回滚比较特殊,如果本次提交是为了恢复到之前的某个提交,那提交消息应该以“revert:”开头,后跟要恢复到的那个提交的标题。然后在消息正文中,应该写上“This reverts commit ”,其中“”是要还原的那个提交的SHA值。

    影响范围

    范围不是固定值,它可以是你提交代码实际影响到的任何内容。例如 l o c a t i o n 、 location、 locationbrowser、 c o m p i l e 、 compile、 compilerootScope、ngHref、ngClick、ngView等,唯一需要注意的是它必须足够简短。

    当修改影响多个范围时,也可以使用“*”。

    标题

    标题是对变更的简明描述:

    • 使用祈使句,现在时态:是“change”不是“changed”也不是“changes”
    • 不要大写首字母
    • 结尾不要使用句号

    正文

    正文是对标题的补充,但它不是必须的。和标题一样,它也要求使用祈使句且现在时态,正文应该包含更详细的信息,如代码修改的动机,与修改前的代码对比等。

    页脚

    任何Breaking Changes(破坏性变更,不向下兼容) 都应该在页脚中进行说明,它经常也用来引用本次提交解决的GitHub Issue

    Breaking Changes应该以“BREAKING CHANGE:”开头,然后紧跟一个空格或两个换行符,其他要求与前面一致。

    git 使用流程规范(merge-request)

    如今很多项目都采取merge request方式来进行codereview,所有掌握merge request很有必要,步骤如下:
    1.现在本地用创建一个本地分支,比如叫xx_branch。
    2.改动xx_branch你需要改动的代码。
    3.进入你的项目根目录下,运行如下命令,将xx_branch推到远程分支。
    git add .
    git commit -a -m ‘xxxxx’
    git push -u origin xx_branch
    4.在gitlab上面操作,进入xx项目下,点击merge request选项,然后选择你之前推到远端的xx_branch和你要合并到哪个分支,比如你要合并到master上。
    5.点击merge request。

    git解决冲突

    1. git stash 
    2. git pull
    3. git stash pop
    4. 解决冲突
    5. git pull
    

    代码合并

    1.单分支合并

    git stash 
    git pull
    git stash pop
    # 合并冲突并进行提交
    git push
    

    2.多分支合并

    # 将my_feature合并到develop
    git clone -b my_feature ***
    git checkout -b develop
    # 将本地的develop追踪远程的develop
    git branch --set-upstream-to=origin/develop develop
    git pull
    # 合并解决冲突,进行提交
    git push
    
    展开全文
  • 0034Git规范指令大全1

    2022-08-04 14:37:25
    0034Git规范指令大全1
  • 一、VCS版本控制系统 version control system(VCS),用于项目中存储、共享、合并、历史回退、代码追踪文件历史等功能。 VCS软件: 2000年以前 2010年以前 ...以下命令可在本地git bash here执行 3.1

    一、VCS版本控制系统

    version control system(VCS),用于项目中存储、共享、合并、历史回退、代码追踪文件历史等功能。

    VCS软件:

    2000年以前2010年以前2010年至今
    CVSSVNGit

    二、Git中的常见概念

    工作目录:是一个目录,用于保存项目中的文件
    暂存区: 是内存中的一块区域,临时存储项目中修改的文件
    本地仓库:是一个特殊的目录,保存项目中所有的文件及每次修改的记录
    在这里插入图片描述

    三、命令

    以下命令可在本地git bash here执行
    在这里插入图片描述

    3.1 基本命令

    • 拉取远程项目代码 git clone [ssh/url]
      找到仓库,复制clone下ssh地址,在本地执行即可拉取项目~
      (前提是已经配置好密钥且有项目权限哦)
      在这里插入图片描述

    • 创建本地新分支 git branch [branch name]

    • 删除本地分支 git branch -d [branch name]
      不能在要被删除的分支中执行改操作!!!
      如果要删除分支“branch1”,应先切换到其他分支,再执行上述命令(若在branch1中执行无效)

    • 本地分支重命名 git branch -m [ old branch name] [ new branch name]

    • 本地切换新分支git checkout [branch name]
      强制切换                             +-f
      创建并切换到该分支           +-b

    • 远程分支拉取到本地 git pull origin <branch>

    • 本地分支推送到远程

      1. git push origin <branch>/git push 本地名称与远程名称相同
      2. git push origin localBranchName : remoteBranchName 本地名称与远程名称不同

    3.2 推送步骤+git规范

    1.git add .将本地修改内容保存至暂存区
    2. git commit –m "提交说明" 提交到本地仓库
    (例:git commit -m “feat: 主题色修改”)

    前缀说明
    feat修补bug
    fix新功能(feature)
    docs文档(documentation)
    style格式(不影响代码运行的变动)
    refactor重构(即不是新增功能,也不是修改bug的代码变动)
    perf性能优化
    test增加测试
    chore构建过程或辅助工具的变动

    3.git push origin <branch> 推送到远程仓库

    3.3 git fetch+Git merge 合并分支

    展开全文
  • git 规范

    2021-07-02 10:51:03
    Git规范 Git推送与合作规范 一、规范简述 为了更好的完成代码版本管理以及多人合作,必须统一Git的推送规范以及一些代码合作上的规范 二、Git代码提交规范 除了项目初始化的时候,禁止使用[git add .]进行修改提交。...
  • 日活千万级公司git使用规格。 目的 1 开发人员 git 使用流程(规范) 2 提交规范 2 分支建立规范 4 新功能开发分支建立规范 4 发布规范 4
  • Git规范:Git提交规范

    千次阅读 2021-01-08 10:21:29
    作用:用于说明Git commit的类别,只允许使用下面的标识。 ① feat:新功能(feature)。 ② fix/to:修复bug,可以是QA(Quality Assurance)发现的BUG,也可以是研发自己发现的BUG。 备注: fix:产生diff并自动...
  • Git 提交规范

    千次阅读 2022-05-02 17:22:40
    Git 提交规范,包含命令行、Commitizen、 [git-commit-plugin、idea插件Git Commit Template
  • GIT基本规范

    2022-03-30 20:39:31
    Git规范 所有使用项目,必须严格按照规范操作,否则不予合并代码、提测、打包上线等后续操作。 基本要求 所有commit必须要有注释,内容必须按照注释格式严格执行, 合理控制内容提交的颗粒度,一次commit含一个...
  • git规范与日志规范

    千次阅读 2019-08-01 14:16:37
    因为要分享git规范,所以今天也顺便做一个总结,这个仅限于对git的开发中和部署时的规范和提交时的日志规范做总结。本文章分两个部分总结git规范,一个是从分支讲解在开发 目录 分支构成 永久分支-master,develop ...
  • git操作规范文档

    2022-04-27 11:09:30
    git操作规范文档 前置条件 # 清除掉缓存在git中的用户名和密码 ( 可能之前有人用过这台电脑 ) git credential-manager uninstall # 记住自己的用户名和密码 git config --global credential.helper store # 配置...
  • Git Commit 规范

    2022-06-26 16:45:43
    git commit 规范

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 72,108
精华内容 28,843
关键字:

git规范