我们最近开始使用Git作为源代码版本工具。我们以集中式方式使用它，其中中央存储库托管在Atlassian Bitbucket上。值得强调的是，Bitbucket上的中央存储库不是。
根据我们使用的Git客户端，我们开始使用e-git Eclipse插件。但它似乎不够可靠和可用，所以我们切换到TortoiseGit（开发人员更熟悉，因为他们中的大多数人过去已经使用过TortoiseCvs或TortoiseSvn）。
我们已经遇到了基本用例的严重的重复反效果问题，例如我们提交或更新本地副本。我们担心当我们得到更详细的用例时，我们分支/合并这可能会变得更糟。
到目前为止我们遇到的主要问题：
从本地存储库推送后，文件从中央存储库中消失的实例，在日志中没有任何跟踪（即它们没有被git删除）。无论使用哪个客户端（e-Git或TortoiseGit），这让我担心该工具的健壮性和可靠性，为什么明确没有git-deleted的文件会突然从中央存储库中消失？当然，无论用于发出git push命令的客户端（SVN做得非常好），一个值得尊敬的工具都应该防止在推送过程中发生这种情况。这可以通过中央存储库不“裸”来解释吗？ （一些Git教程建议使用裸存储库进行集中式工作流程）
从中央存储库同步本地存储库（使用TortoiseGit“pull”命令）没有应该具有的简单结果，即与中央存储库保持同步的工作副本（例如与SVN相比） ）;相反，它将来自中央存储库的更新应用为对本地工作副本的修改，然后需要将其提交并再次推送到中央存储库。如果没有 - rebase 选项，可以使用TortoiseGit的简单“拉”命令吗？ （一些Git教程建议使用“pull --rebase”而不是简单的“pull”来避免在从中央存储库更新本地存储库时“合并提交”）
Git客户端（e-Git 3.0.0和较小程度的TortoiseGit 1.8.7）是否足够可靠和健壮？ Git客户端工具的不可靠性是否会导致上述问题。如果是这种情况，仅限于使用没有客户端的git命令行，仍然会引起关注：在一天结束时，开发人员不希望使用命令行进行频繁操作，如提交和更新等，因为这可以要适得其反，容易出错，他/她最好希望将代码版本控制集成到IDE中。
总之，基本问题是：
答案 0 :(得分：1)
这里有很多问题。
文件从中央存储库中消失后，从本地存储库推送，在日志中没有任何跟踪（即它们没有被git删除）的实例。无论使用哪个客户端（e-Git或TortoiseGit），这让我担心该工具的健壮性和可靠性，为什么明确没有git-deleted的文件会突然从中央存储库中消失？当然，一个值得尊敬的工具可以防止在推送过程中发生这种情况，无论用于发出git push命令的客户端是什么（SVN都做得非常好）。
除了误解（即文件不是真的消失）之外，对于从代码库的所有版本中消失的文件的唯一合理解释是有人搞砸了并进行了非快速更新分支并在此过程中湮灭了文件。 Git确实允许这种情况发生，但这种潜在危险的更新很容易被关闭，通常应该关闭。一些Git托管系统（可能包括Bitbucket）支持ACL来控制允许哪些用户执行非快进更新。
如果确实发生了这种情况，那么如果你在对象有机会被垃圾收集之前合理地快速行动，你应该能够恢复丢失的东西。
这可以解释为中央存储库不是“裸”吗？ （一些Git教程建议使用裸存储库来实现集中式工作流程）
不，但目前还不清楚为什么你的中央存储库不是裸露的。默认情况下，Git拒绝推入非裸存储库，虽然背后的推理可能不适用于你，但我认为没有非裸存储库的优势。
从中央存储库同步本地存储库（使用TortoiseGit“pull”命令）没有它应该具有的简单结果，即与中央存储库保持同步的工作副本（例如与SVN相比）;相反，它将来自中央存储库的更新应用为对本地工作副本的修改，然后需要将其提交并再次推送到中央存储库。这可能是由于没有--rebase选项而使用TortoiseGit的普通“拉”命令吗？ （一些Git教程建议使用“pull --rebase”而不是简单的“pull”来避免在从中央存储库更新本地存储库时“合并提交”）
为了避免这些合并提交（我同意这是一个麻烦），而不必在每个推送命令中指定--rebase，branch.autosetuprebase和branch.<name>.rebase配置选项可能会有用。有关详细信息，请参阅git-config(1)手册页。
答案 1 :(得分：0)
回答问题＃1：是的，值得使用。查看Atlassian的SourceTree。还可以从命令行了解Git。了解你的工具。 ：）
Git中的合并更容易，更准确。
＆lt; views＆gt;坦率地说，如果你有许多开发人员的代码库和一个优先级不断变化的混乱的商业环境，我不喜欢使用其他任何东西。＆lt; / opinion＆gt;
回答问题＃2：我发现此博文非常有用：A successful Git branching model。我知道“分支”听起来并不像“工作流程”，但是对于Git来说，它们是紧密相连的。 Git在线书籍也有一个很好的概述：Distributed Workflows - gitscm.com。