gerrit

zipfile模块用来做zip格式编码的压缩和解压缩的，zipfile里有两个非常重要的 class, 分别是 ZipFile和 ZipInfo, 在绝大多数的情况下，我们只需要使用这两个 class就可以了。 ZipFile是主要的类，用来创建和读取 zip文件而 ZipInfo是存储的 zip文件的每个文件的信息的 zipfile的用法 压缩： >>> import zipfile >>> z=zipfile.ZipFile("laxi.zip","w") >>> z.write("a.log") >>> z.write("f1.log") >>> z.write("f2.log") >>> z.close() 解缩： >>> z=zipfile.ZipFile("laxi.zip","r") >>> z.extractall() >>> z.close() 解压到指定的文件夹中，如果文件夹不存在，则新建 >>> exampleZip=zipfile.ZipFile("a.zip") >>> exampleZip.extractall("/home/ubuntu/Test") >>> exampleZip.close() >>> import zipfile >>> z=zipfile.ZipFile("a.zip",'r') >>> for i in z.infolist()

一、安装 0.国内镜像 首先，推荐两个地方，也就是国内镜像来下载源码，强烈建议你看完，因为都一样的 科大源 、 清华源 注意事项：如果你不编译源代码，装源代码的磁盘格式，是任何格式都可以，但是你如果要在MacBook上编译源代码，那必须把磁盘格式变成Mac的日志格式，区分大小写的，也就是这个格式： 1.安装repo和Git Git的话，就自行搜素怎么安装了，这里介绍怎样安装repo。 mkdir ~/bin PATH=~/bin:$PATH curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo chmod a+x ~/bin/repo 运行 repo help 可能会报错，或者有提示没有获得完整版 问题1.提示没有获得完整版 问题2.提示没有这个命令 解决第一个问题： 所以，要下载两个文件 第一个就是clone.bundle https://gerrit.googlesource.com/git-repo/clone.bundle 第二个就是git-repo https://gerrit.googlesource.com/git-repo 将clone.bundle复制到git-repo文件夹中 然后把git-repo这个文件夹中的所有文件都复制到上面创建的 ~/bin/ 目录下

gerrit上提示代码冲突的时候，我们首先会想到rebase下，不行的话就只能解决冲突了，最简单的做法是我的另一篇博客https://www.cnblogs.com/zndxall/p/9140813.html 中的方法，但是有的时候还是会出现问题，报错commit xxxx is a merge but no -m option was given,如下： 或者执行git cherry-pick 4e73b64a5fc251e6ff82aa1db4316bd4ecd389d5 是一样的效果。 出现这个问题，是因为提交的代码之前pull 了其他人的代码并合入了自己本地的代码，产生了一个merge操作以后，又push到代码仓，就会出现这种情况，我们看下他的提交日志： 分3个点解释，标记“1”很明显是一个merge操作，标记“2”是他自己的改动，标记“3”我们看到parent节点有两个,一个merge里有多个父节点，cherry-pick的时候至少要指定一个父节点，可以用-m parent-num来指定，parent-num 默认从1开始，比如上面的两个父节点， 上面一个父节点29b3eb321d8f512616fad12ce40d7ed22d5d4371的parent-num 为1 ，

【今日推荐】：为什么一到面试就懵逼！>>> 本文作者：yanxin1563 本文作者： Yunpeng-基础技术 前言 百度App从单一的搜索工具发展到今天以搜索和Feed流为双引擎的综合性内容消费服务平台，其复杂程度已然不可同日而语矣。 作为一个日活过亿的超级App，业务规模庞大，相关技术人员超过千人，客户端支持主流的移动技术，涉及近百业务方，技术形态复杂，各种组件近三百个，代码百万量级，由此带来的工程化问题是技术团队的一个极大挑战。 项目的膨胀导致了很多不起眼的小问题被无限放大，组件管理不规范、编译时间长、工程文件合并冲突、Xcode默认非彻底编译隔离等等问题，导致开发人员在开发环境上耗费了大量时间。目前业界较流行的工具对于大规模工程的支持力度相对较弱，实践起来总是有些掣肘，难以达到理想状态。 EasyBox的诞生，就是致力于为超级App量身打造一套现代、高效、优雅的研发工具链。 这篇文章的主要目的是 站在工具链的角度 上，分享一下我们在实践工程化过程中一些经验。 概述 EasyBox主体由工程组装器(Installer)、多仓库管理工具(MGit)、二进制管理工具(LFS)三部分构成，分别负责工作区的构建(组件依赖分析、工程的生成与组合)、源码仓库的管理以及二进制的管理。EasyBox架构图: 由多仓库管理工具克隆所需仓库源码，由二进制管理工具下载二进制包

本文作者：francisk84 git的诞生历史 -- 摘选自《Pro git》 Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。 到 2002 年，整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。 到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统。 他们对新的系统制订了若干目标： 1. 速度 2. 简单的设计 3. 对非线性开发模式的强力支持（允许成千上万个并行开发的分支） 4. 完全分布式 5. 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量） git push时的refs/for/[branch_name]和refs/head/[branch_name] 谈到git push时的refs/for/[branch_name]指令，其实它是 Gerrit 工具的一种机制。简单的说，Gerrit为了保证每次代码提交都强制开启代码评审

0.如果Gerrit提交使用一下命令会报错 # git push origion master ! [remote rejected] master -> master (prohibited by Gerrit) 1.解决 # git push origion HEAD:refs/for/master 点赞 收藏 分享 文章举报 慢慢的燃烧 发布了755 篇原创文章 · 获赞 464 · 访问量 247万+ 他的留言板 关注 来源： oschina 链接： https://my.oschina.net/u/4274162/blog/3225126

本文作者：yanxin1563 本文作者： Yunpeng-基础技术 前言 百度App从单一的搜索工具发展到今天以搜索和Feed流为双引擎的综合性内容消费服务平台，其复杂程度已然不可同日而语矣。 作为一个日活过亿的超级App，业务规模庞大，相关技术人员超过千人，客户端支持主流的移动技术，涉及近百业务方，技术形态复杂，各种组件近三百个，代码百万量级，由此带来的工程化问题是技术团队的一个极大挑战。 项目的膨胀导致了很多不起眼的小问题被无限放大，组件管理不规范、编译时间长、工程文件合并冲突、Xcode默认非彻底编译隔离等等问题，导致开发人员在开发环境上耗费了大量时间。目前业界较流行的工具对于大规模工程的支持力度相对较弱，实践起来总是有些掣肘，难以达到理想状态。 EasyBox的诞生，就是致力于为超级App量身打造一套现代、高效、优雅的研发工具链。 这篇文章的主要目的是 站在工具链的角度 上，分享一下我们在实践工程化过程中一些经验。 概述 EasyBox主体由工程组装器(Installer)、多仓库管理工具(MGit)、二进制管理工具(LFS)三部分构成，分别负责工作区的构建(组件依赖分析、工程的生成与组合)、源码仓库的管理以及二进制的管理。EasyBox架构图: 由多仓库管理工具克隆所需仓库源码，由二进制管理工具下载二进制包，然后组装器根据描述表生成对应工程

来源： https://www.cnblogs.com/jiayuexuan/p/9041299.html gerrit和git 1.git Git是什么？ Git是目前世界上最先进的分布式版本控制系统。 SVN是集中式版本控制系统。 Git与svn比较 相同：能记录文件的所有更改记录。这样是为了大量更改后，可以有记录回到过去，而不用采用 Copy 旧代码另存为某文件，然后某个时间从大量文件中找你需要的历史记录，版本控制帮我们做到了历史记录的存储，可以方便地查询及回滚到过去的某一版本。 区别：分布式相比于集中式的最大区别在于开发者可以提交到本地，每个开发者通过克隆（git clone），在本地机器上拷贝一个完整的Git仓库。 SVN 是集中式系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器哪里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，带宽够大，速度够快，如果在互联网下，如果网速慢的话，就不方便了。 Git 是分布式版本控制系统，那么它就没有中央服务器的，每个人的电脑就是一个完整的版本库，这样，工作的时候就不需要联网了，因为版本都是在自己的电脑上。既然每个人的电脑都有一个完整的版本库，那多个人如何协作呢？比如说自己在电脑上改了文件A