一个半小时的,耗时一个小时的旁听项目的故事。

简单! 这听起来像是要花上最长时间的工作!

这就是一切的开始。

快进半夜后,我想出了如何为存储库中的22个提交中的每一个上载库快照。

为什么编写开源如此有益。

故事背景。

好吧,让我们备份一下。

听说过ExoPlayer吗? 那是Google的一个很棒的播放器库。 是的,这是一个具有演示应用程序的应用程序,该应用程序以前能够在后台播放Youtube视频(有人为此功能付费使用YouTube Red?????)。

Google开发人员发布ExoPlayer 2.xx时,他们曾考虑使用不同的程序包名称发布ExoPlayer 2,但他们似乎忘记了更改已发布快照的artifactId 所有这些使它成为:

  1. 可以同时使用ExoPlayer 1和2(在迁移到新版本时)。
  2. ????不能同时导入ExoPlayer 1.xx和ExoPlayer2.xx。 所以你不能这样做:
compile ‘com.google.android.exoplayer:exoplayer:r1.3.1’
compile ‘com.google.android.exoplayer:exoplayer:r2.5.3’

即使这两个依赖项中的代码以两个不同的包(分别为com.google.android.exoplayer1com.google.android.exoplayer2 )提供。

我当时正在使用的其中一个应用程序(发生在大约10个月前)使用了ExoPlayer1。我真的想以尽可能小的代码增量将其迁移到ExoPlayer 2(这是一个很大的应用程序)。 我不想一次全部迁移。

我想:

实际上,这很容易解决。 最终,Google确实以不同的软件包发布了ExoPlayer 2。 因此,使用该代码无需进行任何工作。 我将创建自己的“库”,该库将重新打包原始代码,而无需添加我的任何代码,并将其在不同的artifactId下发布。
简单! 这听起来像是要花上最长时间的工作!

所以我开始这样做……但是在我工作的中间,我以一种非常典型的方式想到:

好吧,如果我需要,其他人也可能需要它。 而且我不能真正确定其他人使用的是与我要迁移的版本完全相同的ExoPlayer 1。 我需要从每个已发布的ExoPlayer 1版本创建快照...

手册开始。

我创建了一个具有ExoPlayer依赖项的库项目,并创建了一个示例项目来测试该项目是否有效。 该示例项目取决于库project和ExoPlayer 2的官方工件。所有程序都可以很好地并行运行。 我手里有一个重新包装好的ExoPlayer 1。

为此,我决定采用一种非常简单的git结构:只有一个分支,每个ExoPlayer 1版本都有一个提交。 这意味着在整个仓库中有22个提交(现在有23个)。

我先告诉你一件事。 我不是git master。 我对它的了解越来越多,但我并不知道所有可能的命令。 别再念了……

所以我开始添加提交。

  1. 我将版本上传到Bintray。
  2. 做出了Initial commit
  3. r1.3.1中添加了一个git标签r1.3.1

然后我向前走。

  1. 代码已更改为r1.3.2
  2. 上载到Bintray。
  3. 新提交: Version r.1.3.2
  4. r1.3.1中添加了一个git标签r1.3.1

问题的开始。

然后,我对4个或5个以上的版本重复了相同的步骤。 土拨鼠日…直到我发现我的提交的命名问题。 你发现多余的东西了吗. r之后 是的,我在撰写故事时没有犯错……我在提交更改时就做到了。

我可以保持原样,只是确保下一次提交是正确的,但是我认为:

这些只是很少的提交,让我们更正此问题,并使回购协议干净利索。

谢谢上帝,我对git rebase -i比较熟悉。 我很快改错了名字。 没问题……直到我发现自己在途中丢失了标签。

好的,没问题,让我们重新标记这些提交。

我也这样做了。 我需要确保下一次提交是正确的。 我开始研究一种使提交名称“自动化”的方法。 对于我的案例,提交模板是最简单且完美的解决方案。

我创建了一个简单的Version r1. 模板,并将其添加到/.git/config中。

[commit]
template = /path/to/my/simple/template.txt

只要我能够在提交时思考一下,此解决方案就可以确保我将来的提交遵循相同的规则。

在那之后,我真的感到自己得到了控制。 尽管我做了一些本来可以避免的工作(重新标记和重新标记),但总体而言,我离这个“图书馆”的最初时间表并不遥远。

方法改变。

我实际上完成了手动添加所有22个提交的工作……我知道,对吧?

为什么编写开源如此有益。

然后,我发现自己在Initial commit弄乱了某些东西……陷入了困境。

显然,仅通过将aar库添加到依赖项中aar会将其捆绑在另一个aar 那时我不知道的东西。 样例项目以某种方式可以正常工作,但是组装好的aar不包括ExoPlayer 1。

????

那正是我对整个事情的想法。 我知道我必须:

  1. 更正Initial commit
  2. 重新上传每个版本的库快照。
  3. 重新标记所有内容

第一步并没有让我那么担心。 我很快找到了解决方案。 这就是所谓的“胖子”。 幸运的是,创建起来并不难。 这样就解决了问题并使它正常工作。

我知道我必须为步骤2和步骤3寻找其他解决方案。

我再也无法手动执行此操作,因为我知道最终“图书馆”将根本无法交付。 我懒得做所有的手工工作。 我知道如果必须第三次这样做(如果再次出现问题),我将把笔记本电脑从窗户扔出去。

要成为一个好的开发人员,您至少需要有点懒惰...

上载库快照

我必须先弄清楚。 如果在修复了Initial commit后,任何上传都出了点问题,我将再次丢失标签(在再次更正基本代码时)。

我正在使用脚本进行Bintray上传。 这就像运行终端命令一样简单。 如果您不必重复22次,则为“简单”。 在那种情况下,它变得“简单烦人”,而不是“简单”。

幸运的是,我很快发现您可以使用git rebase -i x选项运行用于提交的终端命令。

在这一点上,即使使用git rebase -i并添加要在commit上运行的命令也需要大量工作。 值得庆幸的是,您还可以使用带有方便的--root参数的非交互式版本的rebase,它将对每个单个提交执行相同的操作,直到到达root为止。 那正是我所需要的:

git rebase -x "./gradlew clean bintrayUpload" --root

片刻之后,一切都完成了。 我希望我知道在最初添加提交时。

添加git标签

这有点困难。 我需要提交消息信息。 我需要一些可以给我格式化的提交主体版本的东西。 经过快速的“搜索会话”,我想到了这个:

git log -1 --pretty=format:”%B”

这给了我当前提交的内容(例如Version r1.3.2 )。 我只需要修剪r1.XY前8个字符(我想要一个简单的r1.XY标签)。

除此之外,我还需要提交哈希来添加标签(虽然不确定为什么……我应该能够将标签添加到当前提交中……nvm)。

git log -1 --pretty=format:”%h”

这两个命令是一个简单的bash脚本:

#!/bin/bash
messageName=$(git log -1 --pretty=format:"%B")
shortHash=$(git log -1 --pretty=format:"%h")
if [ "$messageName" = "Initial commit" ]; then
tagName="r1.3.1"
else
tagName=${messageName:8}
fi;
git tag $tagName $shortHash

我可以再次使用git rebase -x "script.sh" --root

几秒钟后…添加了所有标签。 我希望以前也知道这一点。

最后的想法。

再次阅读该故事,我觉得这是过程中最耗时的部分,似乎就像我轻松经历的一样。 好吧,不是那样的。 实际上,我大部分时间都花在弄清楚如何上传22个快照以及如何自动标记所有提交上。 让我们清楚一点。

尽管我在整个晚上的搜索中花费了大量时间,并根据自己的需要测试了不同的解决方案,但我并没有把这段时间视为“浪费”。

最初,我认为从本质上讲这是一个上传具有单个依赖项的库的简单项目。

我最终学习了这个过程:

  1. 真是个“胖子”。
  2. 如何在git仓库中使用提交模板。
  3. 如何使用git rebase -x "cmd"
  4. 如何重新设置所有提交,直到--root为止。
  5. 如何格式化git log输出。
  6. 如何在bash中进行子字符串化。

如果我没有决定编写该 ,那这些就是我不会“暴露”的六件事。

我要做的很大一部分原因是我不想过分地运送图书馆(不要说“不完美”)。 我想保持回购协议尽可能的干净。

尽管我知道没人会看到这个项目进行了多少工作,但是我下意识地知道这代表了我在工作时可以保持我的存储库多么整洁和优雅。

开源就是这样 :它向世界展示了您的技能。 一方面,它会使您感到不舒服和脆弱。 另一方面:它会带来压力,要求做得更好,并在您运送东西时迫使您进行改进。 随着质量的提高,您的工作会吸引更多的受众。 您获得的受众越多,对更多产品及其质量的期望就越高。

所有这些就像使用自动手表一样。 腕部几乎不动,您就可以使手表运行数天。

自我完善的永恒动力。

如果您喜欢这篇文章,请表示支持! 拍手,关注,评论,分享。

这真的很重要!

为什么编写开源如此有益。
为什么编写开源如此有益。

From: https://hackernoon.com/why-writing-open-source-is-so-beneficial-1f290bc90a58

相关文章: