使用Git进行版本控制的经验（好的或坏的）与Git的不同版本如何协同工作有什么关系？
短篇小说：
我正在考虑将Git用于一些计划中的家庭项目，但由于我使用来自存储库的默认包的hodge-podge系列设置将意味着不同的完整版本。我计划在运行Ubuntu 8.04的服务器上保留一个主存储库（其他人可能正在阅读和分支），如果我使用标准存储库中的pakages（可能会升级到10.04），这意味着v1.5.x未来几个月，这意味着Git包升级到1.7.x），但是我的上网本运行的是较新的9.10，它有Git v1.6.x.我的主要Windows机器我还没决定如何处理（因为没有使用它的软件包管理可以直接获得任何版本，或者我可能使用Ubuntu VM进行开发）。
作为一个额外的复杂功能，我可能也希望与目前在GitHub上的几个项目进行交互（并且可能会删除我的一些代码，因为我打算将它作为开源软件）。
我很高兴编译我自己的版本最好的版本（即最接近GitHub运行的稳定版本，大概是1.7.x）如果这是唯一可行的方法，但如果我是不太可能遇到在1.5 / 1.6 / 1.7之间进行更改的问题，那么我更愿意继续使用标准存储库版本来尽可能轻松地更新/升级Git。
经过几次搜索后，我没有找到任何对此的引用，这让我相信跨版本兼容性是好的（如果有重大问题我希望在发行说明中明显提及并找到人们询问如何处理问题的各个地方的帖子。）
答案 0 :(得分：4)
当涉及到存储库格式和布局时，我认为最后一次更改来自Git 1.4.3 to 1.5.0。
Jakub mentions here根据您的Git版本可能不支持的一些功能，但在“旧版本无法处理使用较新版本创建的存储库”方面不应存在任何不兼容问题”。
Git 1.5.x，1.6.x和1.7.x都应该没有任何问题地管理同一个存储库。
2017年更新：我确认git repo 2.x仍适用于git repo 1.7
答案 1 :(得分：3)
是的，到目前为止，可以确认1.5.x和1.6.x之间的版本兼容性。 有一次，我在使用git 1.4.x撤消某些操作时遇到了问题，因为并非所有git版本的命令都可用。
答案 2 :(得分：1)
是的，他们一起工作得很好。
答案 3 :(得分：1)
如果服务器具有“description”-file的较旧默认内容，1.7客户端可能会遇到1.5服务器问题：
Unnamed repository; edit this file to name it for gitweb.
1.7不接受上述内容。