BitBucket引入灾难恢复和合并策略

最近发布的BitBucket Server和BitBucket Data Center 4.9让定义灾难恢复策略及设置首选合并策略等成为可能。

BitBucket Data Center通过将一个BitBucket Server主实例复制到一个“冷备”实例实现灾难恢复支持，这两个实例可以处于不同的地理区域。为了实现灾难恢复，BitBucket的典型部署是，让多个BitBucket节点处于“冷”状态，而共享的文件服务器和数据库处于“热”状态，这样，就可以进行复制。一旦出现灾难，所有请求都会被重定向到备用实例，实现宕机时间最小化。

BitBucket Server 4.9还允许团队通过定义一个默认选项指定他们首选的Pull请求合并策略。此前，BitBucket会自动选择最合适的合并策略，比如启用Fast-forward合并，或者强制显式合并。在4.9版本中，管理员可以定义一种默认的合并策略以及合并时可选的策略。例如，如果团队希望以丢失单个提交的细节信息为代价保留一个干净的分支，他们就可以选择Squash合并策略。这样，PR中的所有提交都会合并到一个提交中。如果希望保留线性历史，则团队可以选择默认的Fast-forward策略。Squash和 Fast-forward策略也可以结合在一起使用。

此外，BitBucket Server和BitBucket Data Center 4.9新增了一种将外部库导入到新库的方法。代码可以从BitBucket Cloud、GitHub.com、GitHub Enterprise和其他任何基于HTTP的Git服务器导入。

本文转自d1net（转载）

团队如何选择合适的Git分支策略 现代软件开发过程中要实现高效的团队协作，需要使用代码分支管理工具实现代码的共享、追溯、回滚及维护等功能。目前流行的代码管理工具，包括CVS，SVN，Git，Mercurial等。 相比CVS和SVN的集中管理，Git具有非常明显的优势，例如：去中心化的代码管理方式减少了开发者对中心服务器的依赖，每个成员在本地都有一个完整的代码库，在不联网的情况下也能提交代码；不同于SVN中的每个分支具有独立的代码，Git中的每一个分支只是指向当前版本的一个指针，Git的分支策略使创建和合并分支变得快捷灵活。 从百度指数，也可以看到Git的优势被越来越多的人所认可。
DVC 使用案例（一）：数据与模型版本管理 数据科学团队常常面临着数据和机器学习模型进行版本化的数据管理问题。我们应该如何一起跟踪数据、源代码和ML模型中的变化？组织和存储这些文件和目录变更的最佳方式是什么？
DVC 使用指南：管理外部数据 ⚠️ 这是针对特定情况的高级功能，除非绝对没有其他选择，否则不推荐使用。 在大多数情况下，dvc add 和 dvc import-url 的 to-cache 或 to-remote 策略更方便。
git常见用法和核心策略 版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。
如何高效回退到特定层级目录？ 这个脚本在经常需要切换目录，并且路径又很长的情况下，非常有用，能够快速进入到你想要的父目录。好好使用这个脚本，将会在目录切换时大大提高你的效率。
Minio分片合并时遇到了一个疑难问题 今天调用Minio的分片合并接口时，遇到了一个错误，困扰了我一整天。因为我始终在自己身上找原因，一度怀疑是自己的逻辑处理有问题，而且自己认为最可能的原因就是自己参数传错了。但是，万万没有想到，原来问题出在Minio服务自己身上。
Confluence 6 在升级过程中查看合并日志 为了监控升级的过程，你应该查看 application log 日志中的输出。 通常日志经常将会显示多个日志实例，这个实例是定义在日志的 INFO 级别的，通常格式如下： WikiToXhtmlMigrationThread-n - Migrated 2500 of 158432 pages, this batch migrated 500/500 without error
针对每一个独立的页面，可能会显示很多日志的消息，但是任何错误将会显示一个独立合并日志，一旦所有的内容都被处理完成后。