精华内容
下载资源
问答
  • 最后一步可能有人会抱怨为什么要打4个字母,能能简化一下,没错,它确实能简化,且看如下演示: 在第一次提交代码时带上 -u $ git push -u origin master 那么以后提交代码直接使用git push就能提交代码啦! ...

    git绝大多数人都了解过并且使用过

    但是很多人只会使用祖传的三步

    • git add . 
    • git commit -m xxx
    • git push origin master

    接下来我要说的并不是介绍其他命令,而是如何简化命令

    最后一步可能有人会抱怨为什么要打4个单词,能不能简化一下,没错,它确实能简化,且看如下演示:

    在第一次提交代码时带上 -u

    $ git push -u origin master
    

    那么以后提交代码直接使用git push就能提交代码啦!

    $ git push

     

    展开全文
  • 很多人这样做,他们将他们想要提交的每个文件都添加.gitignore文件中。 我也那样我使用git add -f添加要跟踪的文件,一旦完成,当这些文件已更改时,git会通知我。 默认分支 你们之间的感知力已经注意,该...
  • 什么问题也可以直接进群 ;8fcc6a2f88552ea44b1411582c94fd124f7bb3ec227e2a400dbbfaad3dc2f5ad"><img alt="QQGroup" src="https://img.shields.io/badge/QQGroup-20867961-blue.svg" /></a> 咨询与交流,...
  • IDEA + github pull request + teamcity运用

    千次阅读 2018-10-11 10:03:00
    首先要来看github工作流的流程,如上图(图为百度)。 那么,为什么要有pull request呢。...这时,我们能在github上看到这个提交,能让老手审查评论,若无问题,就可以合并提交到master。 那今天要来整...

    Github Flow

    首先要来看github工作流的流程,如上图(图为百度)。

    那么,为什么要有pull request呢。最近有个新的需求,不想要让一个新手直接提交合并代码到master分支。那么 pull request的需求就很合适。让新手提交到自己的分支,然后在创建pull request。这时,我们能在github上看到这个提交,能让老手审查评论,若无问题,就可以合并提交到master。

    那今天要来整合teamcity与pull request。就是当有人创建了要与master合并的新的pull request时,teamcity就能捕获到该请求,并build。这时通过后,我们可以查看代码的改动,当然之后还是要去github合并。(这里的合并好像有点繁琐,不知道是否在teamcity中直接有合并操作,笔者在此还没有找到,大家若是知道请评论告诉我下~~)。

    好了,直接上操作吧。

    在IDEA中,先创建个分支,并提交代码(要的是与master分支不同的代码,否则会不能创建pull request)。完成后就可以create。

    没错,它是在最下面。

    标题和描述大家根据代码提交来写。重要的是base branch这里要选择本次提交将与那个分支合并。这里会关系到teamcity的配置

    这里会弹一个警告,说到分支没有完全合并。这里可以“Yes”跳过。

    那我们先来到github中查看我们的pull request

    那么我们去teamcity中配置并查看一番吧。还不知道怎么配置的朋友可以去看下我之前的两篇文章。这里直接上配置,其实也很简单。

    就是这么一句,值得注意的是,在IDEA中create pull request时选择的合并分支,要与这边的Default branch监控的分支一致哦。

    这里输入的就是一句

    +:refs/pull/*/merge
    or
    +:refs/pull/*/head

    这俩者有什么不同呢,这里引用一下

    https://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/ 的说法。

    好了!那到这边我们就配置好了。当我们在IDEA中create pull request时,在teamcity中会显示:

    其中的“3”与github中的pull request次数对应,我们点进去可在teamcity中查看代码的变化。

    点进去即可查看代码的更变了。

    这是笔者最近发现比较有意思的功能,可能还有些地方不太了解。还请大家斧正

    展开全文
  • 且有一些公司自用的东西,所以提交记录可以参考,但直接使用master分支。 release:是相对稳定的最新代码分支,也是RAP对外打包的分支 其它分支:根据开发需要,大的版本会以版本号分支名,打一些临时分支。 ...
  • 为什么要用LiveEventBus 生命周期感知 消息随时订阅,自动取消订阅 告别消息总线造成的内存泄漏 告别生命周期造成的崩溃 范围全覆盖的消息总线解决方案 进程内消息发送 App内,跨进程消息发送 App...
  • 选择模型文件夹中的模型配置文件(一般model.json/index.json,必须包含model/textures/motions三个字段,没有的话可以尝试自行添加),将会导入该配置文件所在的文件夹 导入的模型如果显示完整,可以【设置 ...
  • 项目安装后跑起来

    2021-01-11 01:29:46
    确保你在提交Bug反馈之前仔细阅读了<a href="https://hexo.io/zh-cn/">Hexo文档</a>,<a href="https://ppoffice.github.io/hexo-theme-icarus/tags/Icarus%E7%94%A8%E6%88%B7%E6%8C%87%E5%8D%97/">Icarus用户...
  • 为什么要主干开发?我用分支用的真的挺好的,你看,标准的Git Flow...”我举双手赞同,因为伟大的黑格尔都说...只能从别的分支合并过来,直接提交到masterDevelop: 所有开发的基础分支,新feature分支从这出去...

    “为什么要主干开发?我用分支用的真的挺好的,你看,标准的Git Flow...”

    我举双手赞同,因为伟大的黑格尔都说过:存在即合理。这句名言出自其《法哲学原理》

    我们这里以Git Flow为例,来看一下分支开发的优劣:

    bb683818f96e3b9e6ff8e12445f0eedb.png

    图片来自于网络

    工作流程:

    • Master: 用来放稳定、随时可上线的版本。只能从别的分支合并过来,不能直接提交到master
    • Develop: 所有开发的基础分支,新feature分支从这出去,也会合并回这来
    • Hotfix: 线上环境出bug,从master开一个hotfix,进行修复,修复完成后,合并回master和develop分支
    • Release: develop分支准备好后,合并到release,经过最终测试并修改,通过测试后,合并回master和develop
    • Feature: 开发新功能,从develop来,最终合并到develop去

    先说优点:

    1. 职责清晰:每个分支都有明确的定位,从哪儿来,到哪去,都很明确
    2. 在制品分离:未完成的功能只存在于feature分支,不会污染到其它分支

    再说缺点:

    1. 分支较多,合并无处不在:光基础分支就4个,再加上feature分支
    2. 规则复杂:因为职责分得很细,学习成本和维护成本就会随之上升
    3. 频繁发布成本高:如果是一个很小的feature,很快就能开发完,我还是切到一个新的分支上,并且合并回来

    小结:

    • 适合同时开发多个版本,互相不影响
    • 适合较重的项目,有长周期的功能开发

    GitHub Flow:

    相对于Git Flow, 流程变得更简单。

    8f7f0e715310e37929d3d7e5f034df86.png

    来自github

    只有一个master长期分支,如果有任何修或者bug,可以先fork一个分支,如果想合并回主干,可以提pull request,然后大家一起code review,没有问题,没有冲突后,可以合并到主干。

    GitLab Flow:

    b260d37d4caa7d9392b9cb7f62aad6a8.png

    来自gitlab

    相对于GitHub而言,多了PRE-PRODUCTION和PRODUCTION环境,其它的都差不太多,也需要提PR,代码审查,合并回主干。

    可以看出,以上三种流程都是分支开发,我们也不难看出有几个关键点:

    • 需要有人审核你的代码。通常这些人也不会只做审核代码这么一件事,那么这个群体就很可能会成为瓶颈。毕竟大家的时间有精力都是有限的。
    • 最终你都需要把代码合并回去。越大的功能,越晚合并,发生冲突的可能性和复杂度会越大。

    相信很多团队都找到了自己较为舒适的方法,来尽量避免这些问题。

    代码审核:

    在人手较足的组织里面,在规定时间内,加大代码审核的投入,如发布前。或在人手较紧的团队里,大家都停下手头的工作,互相review(事实证明自己review自己的代码那就是走过场,到不是说自己不客观,而是每个人都有自己的思维习惯,很难在代码review的时候,就完全切换到另一套模式,像换了一个人一样)。

    分支合并:

    有的团队将职责都划分的很清楚,公用的代码由谁负责,修改流程如何如何。模块之间如何交互,提前都设计清楚,尽量减少冲突。

    不管咱们怎么优化流程,都有执行不到位的时候,回过头我们就会提出更多的条条框框来约束自己和别人。

    不管怎么提前设计,都会有没考虑到的地方,毕竟软件行业最不变的就是变化。越细的责任划分,也意味着越明确的团队壁垒,一旦商量好了接口,就很难变动,不管对错,先换这个来一版。如果再和KPI挂上钓,那就是难上加难了。

    在套装软件的背景下,以上流程运作起来匹配度很高。

    • 我们需要同时支持多个版本。因为不同的用户可能需要不同的版本,用户需要去学习这些版本之间的差别,找到那个适合自己的。
    • 我们不需要频繁推出新功能,可能半年一次,或者一年一次。

    不过还有另一种软件 - 互联网服务(网站、手机端、智能设备等),需求就不一样了:

    • 用户并不需要关心自己使用的是哪个版本,好用就行。有的甚至不需要安装,打开既用
    • 需要频繁发布新的版本和新的功能,有的每天发布好多次。因为市场的竞争太过激烈,用户的需求也在很快的发生变化

    从以上特性可以看出理念的转变:

    690feb81e4d24fa5d9507add7509a861.png

    以产品为中心到以用户为中心

    不管是以产品为核心还是以用户为核心,其实大家的目的都是一样的 - 帮助用户解决问题,创造价值。不同的点就是重心在哪里。互联网之所以发展如此迅速,我相信和TA的理念 - 以客户为中心是分不开的。

    那如何做到以人为本,快速交付价值呢?

    站在Git这一类产品的角度,我们开发人员就是用户。站在我们自己开发的服务角度,使用我们服务的人就是我们的用户。那我们现在站在客户的角度,来梳理一下我们的诉求:

    1. 如何让合并代码不会成为恶梦,我只想开心的写代码,不想一合并就有很多冲突
    2. 我的代码为什么要被审核?如果是为了保证质量,是否可以提前告诉我标准,我可以按标准来写,梳理测试用例。如果是想帮助我提高我的代码技能,是否可以提前沟通,我也可以查漏补缺
    3. 我为什么要关心服务的版本号,我只是想查看一下我的工资是否到账了
    4. 年底了,大家都会收到年度账单,我也想看看我的储蓄卡这一年的账单。如果现在没有,两天后我能不能看到?

    主干开发 - Trunk Based Development

    037163068fb9295776d481f43c496769.png

    来自GoCD

    工具本身没有对错,如何运用,将会决定用起来是否顺手。我们用主干开发再来重新回顾一下上面的几点诉求,看是否可以称心如意:

    如何让合并代码不会成为恶梦,我只想开心的写代码,不想一合并就有很多冲突

    主干开发的关键并不是所有的开发必需在主干上,而在于合并的时机。和长生命周周期分支相反的是,建议小步快跑,频繁提交。也是基于这一点,持续集成(CI),才可能发生。在实际操作中,会要求团队成员每天都提交,最好一天提交多次。当然,提交是有前提条件的,也就是经过自测试,没有问题的代码,才能提交。那么这里的测试最好是自动化,并且耗时较短,比如只用跑单元测试,但重点是都要自动化 -- 尽可能自动化一切可以自动化的步骤。如果大家都能频繁提交,当然也会遇到冲突,但这种冲突通常足够小,可以接受,因为提交的量足够小,并且在冲突的时候也可以直接和团队成员沟通,看是否有需要重构的地方,发挥大家的主动性。在每日站会和IPM等其它的敏捷实践流程中,都可以提前发现一些有共性的地方,都可以提前沟通和探讨,共同设计。

    我的代码为什么要被审核?如果是为了保证质量,是否可以提前告诉我标准,我可以按标准来写,梳理测试用例。如果是想帮助我提高我的代码技能,是否可以提前沟通,我也可以查漏补缺

    如上所述,主干开发会有很多机会能和团队发生充分交流,再比如团队的代码review,也会是个很好的机会,方便大家互帮助,给出修改意见。而不用等到最后,有专人审查代码,更别说是平常没有参与项目的人。

    我为什么要关心服务的版本号,我只是想查看一下我的工资是否到账了年底了,大家都会收到年度账单,我也想看看我的储蓄卡这一年的账单。如果现在没有,两天后我能不能看到?

    从以上两点可以看出,用户是对版本号不敏感的,因为我是想用你的服务帮我解决问题,而不是相对技术的术词 - 版本号。用户的需求变化很快,也想马上就能用上。

    如果想要持续交付价值,就需要将已经测试通过的代码,处于随时可以发布的状态,那么这个测试因该是持续的,自动的。所有的这些才能让持续交付价值得以保证。

    从以上需求,情景出发,我们可以将主干开发做个小结。

    优势:

    • 只有一个长期存在的分支,容易理解,易于实施
    • 强调人的主动性,以人为本
    • 强调团队协作,而不是监管审查
    • 测试内嵌、自动化,质量有保障
    • 随时交付价值,贴近客户

    劣势:

    • 线上版本会引入未完成的代码

    关于线上引入未完成代码的劣势,这里提供一个解决方案及实践 - Feature Toggle(特性开关):

    • 所有的feature toggle因该是短生命周期的,有创建,有消亡
    • 用相应的工具去管理这些feature toggle的生命周期

    可以看出,分支开发和主干开发各有所长,我们在做具体选择的时候是否需要关心以客户为中心,以人为本,持续交付价值。

    2020了,从事着创造性工作的开发者们,记得也要对自己好一点。

    最后留一个问题和大家一起探讨:

    现有的版本控制系统都是由产品背景的大神们创造出来的。如果要以人为本,持续交付价值,这个时候该如何设计版本控制系统呢?

    全文完


    baf8627bc8b513c96302a3fea52d7274.png
    展开全文
  • 请输入提交消息来解释为什么这种合并是必要的 git 在pull或者合并分支的时候有时会遇到这个界面。可以不管(直接下面3,4步),如果要输入解释的话就需要: 按键盘字母 i 进入insert模式 修改最上面那行黄色合并...

    今天把自己写的项目分支合并到master时,出现以下问题

    问题一:

    Please enter a commit message to explain why this merge is necessary.

    请输入提交消息来解释为什么这种合并是必要的
    在这里插入图片描述
    git 在pull或者合并分支的时候有时会遇到这个界面。可以不管(直接下面3,4步),如果要输入解释的话就需要:

    1. 按键盘字母 i 进入insert模式

    2. 修改最上面那行黄色合并信息,可以不修改

    3. 按键盘左上角"Esc"

    4. 输入":wq",注意是冒号+wq,按回车键即可


    问题二:

    在这里插入图片描述
    解决办法:

    第一步:回到合并前状态

    git merge -abort // 中止合并
    rm .git/.MERGE_MSG.sw* //删除 vim 非正常关闭产生的文件

     git merge -abort  // 中止合并
     rm .git/.MERGE_MSG.sw* //删除 vim 非正常关闭产生的文件
    

    第二步:重新合并

    合并提交信息页面,使用 :wq! 或者 :q! 正常退出 VIM ,就能正常合并。
    PS: 如果 .git/MERGE_* 文件中 只有 MERGE_MSG 文件的话,不用执行 git merge -abort ,直接删除 .MERGE_MSG.sw* 文件就好。

    其实就是两个分支在合并的时候合并文件非正常退出,或者合并文件正在被另一个程序修改(换句话说就是别人也在执行两个分支合并这件事),我觉得最佳方案是,先终止合并,删除 vim 非正常关闭产生的文件,询问团队内是否有人在执行合并,如果没人,此时再重新执行合并。


    问题三:

    fatal: You have not concluded your merge (MERGE_HEAD exists). Please, commit your changes before you
    

    解决办法:

    保留本地的更改,中止合并->重新合并->重新拉取

    git merge --abort   //中止合并
    git reset --merge   //撤销合并
    git pull            //拉去代码
    

    问题四:

    在这里插入图片描述
    解决办法:

    git reset --hard head  //回退版本信息
    

    该命令是回退版本信息,在Git中,用HEAD表示当前版本,上一个版本就是HEAD^, 上上一个版本就是HEAD^^, 当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100。

    在这里插入图片描述

    展开全文
  • Gerrit 创建分支

    2020-06-01 18:29:50
    一、为什么要做分支管理: 1.发了版本需要做一个版本分支,如果此版本出了bug 可以切换此版本修改bug,以后可能在某一个版本节点上延伸出新的分支 2.需要一个开发版的分支用来开发新的功能,因为很多情况下都是...
  • ThreadLocal提供了一种访问某个变量的特殊方式:访问的变量属于当前线程,即保证每个线程的变量一样,而同一个线程在任何地方拿的变量都是一致的,这就是所谓的线程隔离。 b. 如果要使用ThreadLocal,通常...
  • 1. 另一种心跳检测机制:检测系统和被检测系统之间并不直接关联起来,而是通过zk上某个节点关联,大大减少系统耦合。 2. 另一种系统调度模式:某系统有控制台和推送系统两部分组成,控制台的职责是控制推送系统进行...
  • 序列化 :既然涉及网络传输就一定涉及序列化,你可能直接使用 JDK 自带的序列化吧!JDK 自带的序列化效率低并且有安全漏洞。 所以,你还要考虑使用哪种序列化协议,比较常用的有 hession2、kyro、protostuff。...
  • 一味地造轮子本身没有错,错在看不到车子,清楚什么轮子最适合,于是就有了四方形,三角形,椭圆形的轮子,同样都是能上路的轮子。我的思维跳跃了那个经典的fuzz造轮子代码。曾经用这个代码Fuzz一个小时的我,就...
  • Git权威指南PDF完整版

    千次下载 热门讨论 2012-12-25 17:53:55
    5.1 修改直接提交吗/ 70 5.2 理解 Git 暂存区(stage)/ 76 5.3 Git Diff 魔法/ 78 5.4 不要使用 git commit -a/ 81 5.5 搁置问题,暂存状态/ 82 第6章 Git对象/ 83 6.1 Git对象库探秘/ 83 6.2 思考:SHA1 哈希...
  • 同时要说明的是,该群是一个学习交流群,如果是程序相关问题,请直接提交issues,接受邮件求助、微信求助和QQ私信求助 BookStack 安装使用手册:https://www.bookstack.cn/books/help 站点 演示站点 服务器...
  • 为什么要有人工审核? 这是遵循运维领域线上操作的流程意识,一个工程师要进行线上数据库SQL更新,最好由另外一个工程师来把关 很多时候DBA并知道SQL的业务含义,所以人工审核最好由其他研发工程师或研发经理来...
  • 如果你要提交 issue 或者 pr 的话请 Github 提交。 在公众号 程序员漫画编程 后台回复 “学习资料”,可获取一份 精心整理的最新 Java 技术干货(视频,电子书,面试资料pdf)。 码云地址:...
  • 如果MySQL服务器从复制服务器,则无论选择什么备份方法,当备份从机数据时,还应备份master.info和relay-log.info文件。恢复了从机数据后,需要这些文件来继续复制。如果从机执行复制LOAD DATA INFILE命令,你应还...
  • 注:①测试使用小米9手机,单表数据量从最小100条最大200W条,字段30个String+一个自增ID,每个字符串长度都在2030长度的随机字符,测试过程没有严格做到控制变量法,所以测试并不是很严谨,仅供参考;...
  • 第五步就直接将项目部署服务器</code></p> 缓存 cache <p>GitLab CI/CD提供了一种 缓存机制</a>,可用于在运行作业时节省时间。 定义全局的缓存策略,如上所说,每个不同的 <code>stage</code>&...
  • 为什么选择 APIJSON? 前后端 关于接口的 开发、文档、联调 等 10 大痛点解析 https://github.com/Tencent/APIJSON/wiki 解决十大痛点 (APIJSON 大幅提振开发效率、强力杜绝联调扯皮、巧妙规避文档缺陷、非常节省...
  • 微前端是什么、为什么要做微前端、qiankun 是什么这些笔者将不再叙述。(文末有彩蛋~) 传送门:可能是你见过最完善的微前端解决方案 & qiankun 下面直接进入实战教程。 实战教程目录详解 鉴于 qiankun 文档...
  • 特征工程是对于特征进行进一步分析,是将原始数据转化成更好的表达问题本质的特征的过程,使得将这些特征运用预测模型中能提高对可见数据的模型预测精度。 本部分内容介绍了常用的特征工程部分的方法,主要分为...
  • 有自己觉得写得不错的Module可以pr提交到下面的库中,造福大家! module共享仓库 群友分享: 行为树与fgui分支(Duke Chiang开发维护) ET学习笔记系列(烟雨迷离半世殇写) ET学习笔记系列(咲夜詩写) 框架服务端运行流程...
  • 小菜鸟的我,每逢看源码时就找不到个准头,看着看着就迷糊了。恰巧今天逛知识星球时,看一个球友的回答觉得非常好,特此转录一下 如何写好注释 请停止代码注释 如何写Java文档注释(Java Doc Comments) ...
  • 图床教程

    2020-12-08 23:55:00
    为什么要使用图床? 一般 MarkDown 添加的图片都储存在本地,本地图片的修改、删除、重命名甚至路径改变都会让图片失效。 图片永不失效的方法是上传图片至图床</strong>,图片的储存位置在互联网...
  • 软件工程教程

    热门讨论 2012-07-06 23:10:29
    问:为什么传统音乐程序不好? 答: 传统音乐程序功能单一,容易令人感到枯燥无味,没有吸引力; 传统音乐程序强调单方向,用户没有参与感; 传统音乐程序设计不够灵活,扩展性差。 项目背景--钢琴练奏师 问:...

空空如也

空空如也

1 2 3
收藏数 41
精华内容 16
关键字:

为什么不直接提交到master