Git 2.23更新（2019年第三季度）：通过传输助手（即智能http传输）进行的"git push --atomic"未能在本地确定其中一个引用更新将失败而无需咨询另一端时阻止推送引用，这已得到纠正。
请参见提交3bca1e7（2019年7月11日），作者为Emily Shaffer（nasamuffin）。
（由Junio C Hamano -- gitster --于提交f87ee7f中合并，2019年7月25日）
transport-helper: enforce atomic in push_refs_with_push
Teach transport-helper how to notice if skipping a ref during push would
violate atomicity on the client side.
We notice that a ref would be rejected, and choose not to send it, but don't notice that if the client has asked for --atomic we are violating atomicity if all the other pushes we are sending would succeed.
Asking the server end to uphold atomicity wouldn't work here as the server doesn't have any idea that we tried to update a ref that's broken.
The added test-case is a succinct way to reproduce this issue that fails today.
The same steps work fine when we aren't using a transport-helper to get to the upstream, i.e. when we've added a local repository as a remote:
git remote add ~/upstream upstream
注意：原子推送智能HTTP传输未起作用，这已在Git 2.24（2019年第4季度）中得到纠正。
请参见
提交6f11942（2019年10月16日），由
brian m. carlson (bk2204)提交。
（由Junio C Hamano -- gitster --合并于提交d45d771，2019年10月23日）
Signed-off-by: brian m. carlson
使用--atomic选项推送多个引用时，服务器应执行单个原子事务以更新引用，使其全部成功或全部失败。
本地或通过SSH进行推送时可正常工作，但是在HTTP上推送时，我们未能将原子能力传递给远程端。
实际上，在整个功能生命周期中，我们还没有向任何远程帮助程序报告此功能。
通常情况下，尽管客户端实际上检查了大多数类型的失败（例如非快进式更新），并且仅中止整个尝试，但事情仍然会发生。
但是，如果服务器端报告问题，例如无法锁定参考位置，则事务不是原子性的，因为我们没有传递适当的能力，并且远程端无法知道我们想要的原子行为。
通过从传输代码中传递选项到远程帮助程序，然后从HTTP远程帮助程序传递到send-pack来解决此问题。
通过此更改，我们可以检测服务器端是否拒绝推送并适当地报告回来。
请注意消息中的差异：远程端报告“原子事务失败”，而我们自己的检查则拒绝推送并显示“原子推送失败”消息。
在远程帮助程序文档中记录原子选项，以便其他实现者可以根据需要实现它。
现在Documentation/gitremote-helpers.txt包括以下内容：
'option atomic' {'true'|'false'}:
When pushing, request the remote server to update refs in a single atomic transaction.
If successful, all refs will be updated, or none will.
If the remote side does not support this capability, the push will fail.
在Git 2.27之前（2020年第二季度），"
git push --atomic"会显示未推送的引用失败，这已得到纠正。
请查看 提交 dfe1b7f, 提交 f38b168, 提交 46701bd, 提交 865e23f, 提交 7dcbeaa (2020年4月17日) 由Jiang Xin (jiangxin)提交。
(由Junio C Hamano -- gitster --合并于提交 5b6864c, 2020年4月28日)
Signed-off-by: Jiang Xin
使用SSH或其他智能协议进行推送时，引用会在发送到“receve-pack”的send_pack()命令之前由函数check_to_send_update()进行验证。
对于原子推送，如果在验证后拒绝了一个引用，则只应将用户推送的引用标记为失败，而不是在所有远程引用上报告失败。
提交v2.22.0-1-g3bca1e7f9f（transport-helper：在push_refs_with_push中强制执行原子操作，2019-07-11）旨在修复HTTP协议的报告问题，但将所有远程引用标记为原子推送失败。
为了解决SSH或其他内置智能协议的状态报告问题，撤销该提交的一部分，并为函数atomic_push_failure()添加附加状态。
它的附加状态除了"REF_STATUS_EXPECTING_REPORT"状态外还有：
REF_STATUS_NONE：尚未标记为“REF_STATUS_EXPECTING_REPORT”。REF_STATUS_OK：假设dryrun或status_report已禁用，则为OK。
原始答案（2016年5月）
我正在向BitBucket服务器推送
只有BitBucket支持团队才能确认以下内容：
- 他们的git主机服务器的确切版本
- 该功能是否已明确停用（
git config receive.advertiseatomic 0）。
我怀疑它尚未激活，因为大多数git客户端可能没有达到我在2015年2月提到的git 2.4或更高级别。
