问题标签 [bitbucket-server]

我正在尝试设计一个遵循以下原则的新工作流程：

• 只有通过了自动验证 (CI) 的提交才应该被合并到主线中（特别是合并状态应该通过 CI 以保持集成分支尽可能原始）
• 只有通过人工代码审查的提交才应该合并到主线中
• 只有通过自动验证的提交才应该由另一个人审查（如果它甚至没有构建和通过测试，不要浪费别人的时间）
• 特性分支应该被 CI 覆盖（独立地，不合并到集成分支中——这对开发人员在开发过程中很有帮助）

我们正在使用 git、Stash 和 TeamCity。这是我想出的，但没有一个是完美的。我正在寻找对我的建议或新想法的调整。

工作流程 1

• 开发人员在 feature/VHPC-1 上开发（TeamCity 中的普通 CI 涵盖了功能分支）
• 功能完成后，开发人员创建一个拉取请求：feature/VHPC-1 --> mainline

• 当拉取请求被其他开发者批准时，它会被 Stash 自动合并到主线中（主线被 TeamCity 中的普通 CI 覆盖）

• 问题：如果存在合并冲突，Stash 将不会执行合并，但是直到合并到主线之后才完全测试合并状态。我们不知道主线是否会中断，直到它发生。

工作流程 2

• 开发人员在 feature/VHPC-1 上开发（TeamCity 中的普通 CI 涵盖了功能分支）
• 开发人员从 feature/VHPC-1 推送到 feature/VHPC-1/review（我们在这里重新设置集成分支，然后进行 CI（测试合并状态））
• 功能完成后，开发人员创建一个拉取请求：feature/VHPC-1/review --> mainline

• 当拉取请求被其他开发者批准时，它会被 Stash 自动合并到主线中（主线被 TeamCity 中的普通 CI 覆盖）

• 问题：测试合并状态和发生集成之间的时间（20 分钟 - 1 天？）允许在集成分支中进行更改，这可能意味着合并状态不再有效。集成分支中断的机会。

• 问题：分支数量的两倍意味着一些额外的复杂性和工作。

工作流程 3

• 开发人员在 feature/VHPC-1 上开发（TeamCity 中的普通 CI 涵盖了功能分支）
• 功能完成后，开发人员创建一个拉取请求：feature/VHPC-1 --> feature/VHPC-1/review

• 当另一个开发者批准并合并拉取请求时，feature/VHPC-1/review 将在合并状态下自动构建和测试，并在成功时自动合并到主线

• 问题：分支数量的两倍意味着一些额外的复杂性和工作。

• 问题：提交必须始终集成到主线中，并且只能挑选出来发布分支。

工作流程 4

• 开发人员在 feature/VHPC-1 上开发（TeamCity 中的普通 CI 涵盖了功能分支）
• 功能完成后，开发人员创建一个拉取请求：feature/VHPC-1 --> 主线 TeamCity 自动为自己添加一个审阅者，并尝试构建和测试拉取请求 - 处于合并状态（使用 Stash 的未记录的 refs/pull -请求/合并）

• 如果自动验证通过，TeamCity 将批准拉取请求。然后，人类可以审查、批准并将其合并到主线中。

• 问题：TeamCity 监控 refs/pull-requests/merge 在集成分支更改时会更改，这意味着当集成分支获得一个新更改时，所有打开的拉取请求都会触发构建。

尽管尽了最大的努力，我们还是让自己在 Git 存储库中使用了一个功能分支。最终结果是 agit diff develop..feature-branch显示了完全出乎意料的差异。

例如，在开发中添加的一个文件在差异中显示为删除。许多其他文件显示了类似的问题，一些缺失，一些添加，许多意想不到的变化。一些应该存在的文件develop甚至没有出现在差异中。当我们通过 Pull Request 查看代码时，我们首先注意到 Atlassian Stash 中的问题。挂起的合并是完全不正确的，在合并期间无法通过标准冲突解决方案来解决。

我们试图破译造成这种情况的原因，我们认为问题源于开发人员对已推送到源的功能分支中的提交执行了多次重置。这是为了“恢复”在拉取请求代码审查期间建议的一些更改。具体来说，我们认为这是事件的时间表。

1. 从开发创建的功能分支
2. 在功能分支上执行的工作
3. 在 Atlassian Stash 中生成的拉取请求（PR 看起来不错，但建议进行一些小的编辑）
4. 开发人员使用重置来恢复一些更改并将这些更改推送到原点
5. 同时注意到开发和功能分支之间的小冲突
6. 开发人员从开发更新功能分支以协调冲突并推送到原点
7. 拉取请求 (diff) 显示出意料之外的差异，与之前的差异截然不同。预期提交的文件丢失，反之亦然
8. 我尝试撤消（还原而不重置）“坏”合并并重试。但是 PR/diff 显示了对于挂起的合并相同的错误更改
9. 然后我了解到开发人员在第一次从开发中合并之前使用了重置。

所以，我有三个问题。

1. 我们如何需要“恢复”一个更正的功能分支，以便我们可以正确地将我们的更改合并到开发中？我的想法是从我们的功能分支中的一个提交中创建一个新的“好”功能分支，该分支已知会在重置之前发生。然后我可以从“坏”功能分支中挑选我们想要的提交到“好”分支中重新创建它。最后，我可以将“好”功能分支合并到开发中并删除“坏”功能分支。

2. 如果我将“坏”功能分支合并到开发中，除了文件的不正确状态之外，还会有任何其他“损坏”泄漏到开发分支中。也就是说，被污染的“坏”功能分支会进一步污染开发分支及其下游的任何东西吗？我当然不打算这样做，但我确实想了解后果。

3. 我所描述的重置会导致我看到的问题还是这可能与其他问题有关？

We have Atlassian Stash installed on a Windows 2008R2 server, and for the most part everything is working nicely. We have an SSL certificate issued by our local on-premise CA and a DNS entry set up so we can go to https://stash/ and it works quite nicely, except in Firefox where it throws a warning (related?).

When using Atlassian's Sourcetree we can navigate and choose a repository, but when we try to clone it we get the following error:

fatal: unable to access https://user@url/scm/etc/etc.git: SSL certificate problem: unable to get local issuer certificate

I get the same error if I try if from the git bash as well. Based on this error, I've tried following the instructions on adding the SSL certificate to the Git as also found on their website, including what is in the comments, to no avail. I have exported the cert through Firefox and through the MMC certificate snap-in, gotten the same results and put it in its own file, combined with the curl file, and no matter what keep getting this error. I have yet to try getting it to work with SSH keys yet since I was hoping to make this easier for my team.

I also tried using ssh myserver and accepting the connection, and I entered my password and restarted; still the same error.

I do not want to simply ignore certificate validation either, since that seems a bit pointless, then.

How can I get this working with our CA-issued cert?

我正在尝试从 Java 类以编程方式连接到 STASH 存储库。我看了一下，找不到任何 Java 客户端来执行此操作。有没有人遇到过？

我想连接到 STASH 存储库的原因是我正在编写一个 Maven 插件，它将转到 STASH 中的 Git 存储库并返回提交列表，然后返回给定标签的 Jiras。

任何帮助将不胜感激。

我在我的项目中使用 Jenkins 进行 CI。现在，我有一个“Dev”构建，只要对任何分支进行提交，它就会由 Stash（git 服务器）触发。

我也在尝试合并我的发布工作流程。这是计划：

• 开发工作使用Promoted Builds 插件将所有构建提升到master
• 发布作业由 Dev 的提升触发

但是，我似乎无法弄清楚如何基于其分支来推广构建。我已经尝试过“根据构建参数立即升级”并将其指定GIT_BRANCH为origin/master. 当我运行构建时，我会在它应该echo %GIT_BRANCH%打印origin/master的时候打印。

BRANCH我还尝试在构建和构建脚本中添加一个字符串参数set BRANCH=%GIT_BRANCH%，以防它实际上需要成为一个参数而不仅仅是一个环境变量。

还是一头雾水。

当开发人员将他的代码推送到功能分支时，我正在使用 Stash 附加组件“Stash Webhook to Jenkins”来触发 Jenkins 构建。

如果 Jenkins 构建失败，我想重置为之前的提交。只有在构建成功时才会进行推送。是否有任何附加组件可用于此或任何其他方式？

Atlassian slug 生成算法或其任何实现是否公开？

我需要检查用户输入的存储库名称是否会有某些 slug。

我发现了很多不同的算法，但我需要确保这是 Stash 使用的算法，其中写到 slug 生成是由 BitBucket 完成的。

这是目前的情况。回购既有公共分支<master>，又有公共<team1>分支：

这两个分支都被视为public。

使用 Atlassian Stash 时，我们希望使用<team1>已交付的最新版本更新分支，<master>因此我们创建了一个拉取请求。源是<master>，目标是<team1>。

但是，在执行该操作时，Atlassian Stash 向我们显示它由于冲突而无法合并，以下是如何为拉取请求解决它们：

但是本指南将导致您将合并冲突推入<master>. 为什么？

这个设置<master>和<team1>分支是否错误并使用拉取请求？

<team1>解决分支中的任何冲突并保持<master>完全不变（直到<team1>将交付回<master>）不是更有意义吗？

我们最近从 SVN -> Git (using Stash) 迁移。迁移之后，我们开始在合并期间看到一些开发人员在他们的特性分支上搞砸了合并的问题。

在上图中，假设 developer1 有一个功能分支 feature1 ，已经完成了他的更改并合并回开发。

Developer2 有一个在 developer1 的分支之前创建的分支，但会存在更长的时间。更改完成后，他将更改从 master 拉入他的分支，解决任何冲突，然后重新合并。

问题是，当 developer2 将更改合并到他的本地分支时，他正在通过首选自己的文件来解决合并冲突。但是，这实际上是覆盖 了一些他没有更改的文件。当他创建拉取请求并合并回 master 时，他有效地将 developer1 的更改回滚到以前的版本。我们可以取消它，因为文件实际上回滚到上一个提交 (SHA) id

问题是，

1. 有没有办法我们可以系统地避免这种情况，即要求 git 拒绝对 master 的任何更改，其中更改 SHA id 实际上是回滚。
2. 当开发人员仅在他们已更改的文件上发生冲突时，合并期间有没有办法

我的谷歌搜索让我看到了一些文章，这些文章建议使用 --rebase 选项执行 git pull 或更改 master 分支的权限，以便它们只允许快进合并。任何一个选项都会有帮助。

在我的公司，我们使用 Stash 作为 git 存储库，它托管在内部数据中心。我想在 AWS EC2 实例上克隆一个存储库。我已经测试了 ec2 实例和 git 服务器之间的连接性，并且能够 ping 通它。

当尝试从 ec2 (RHEL 6) 实例上的 Stash 克隆时，我收到一个错误：

这是我正在使用的命令：

我可以毫无问题地将相同的存储库克隆到我的笔记本电脑上。