我理解在本地提交非工作代码是非常正常的，并且一旦它工作就压缩+推送。 但是，在非主分支上，推送一个无法运行的代码版本以便与其他开发人员共享是可以接受的吗？
答案 0 :(得分：0)
使用git时，应始终有一个良好的工作流程，每个人都可以以一种漂亮的结构方式进行合作。您的问题的一个示例是使用多个分支。我使用的工作流程如下。
主分会
主分支是仅包含项目版本中的工作代码的分支。只有项目版本2.0这样的完整工作项目才会committed和pushed到此分支
<强>开发
development分支是您正在开发的分支。在这个分支上not-working代码不是问题，因为只有这个分支用于开发，而主分支用于分段和实时。
您还可以选择在此分支上创建第三个分支，例如名为bugs的分支，您可以push commit并处理not-working代码。
通过使用这些工作流程，您可以将所有内容保存在自己的位置并进行组织。
答案 1 :(得分：0)
我无法接受这样一个事实，即提交一个非工作代码，提交假设是代码的快照。
如果接受提交代码的非工作副本，那么在代码中发现未来的回归将是困难的 - 几乎是不可能的。
如果你想追溯你的步骤以找出哪个提交引入了某个bug，你会发现你的自己经历了一些不能编译的提交...
这就是说，我甚至无法开始谈论推动代码的非工作副本。
答案 2 :(得分：0)
我不确定是否有正确的方法＆＃39; （例如，主要是noy）。我更喜欢一直检查可编译的代码。我使用补丁文件来分享非工作变化。
git diff＆gt; output.patch
patch -p0＆lt; output.patch
注意它可能是p1 ...从键盘上发布这个。如果补丁可能会卡在我身边，我还会包含当前的哈希，所以我知道它的差异来自。