在我们的工作环境中使用GIT的最佳方法是什么？ [关闭]

Posted 2021-05-03

我们目前不使用任何类型的版本控制软件。我们最近开始使用Eclipse，我们的源代码在网络驱动器上维护。创建了一个Eclipse项目，每个人都在他们的机器上将项目导入Eclipse。由于我们的设置方式，我们总是在一整天都陷入清洁/构建循环中，这会影响生产力。

我们想开始使用某种VCS（很可能是GIT）。我正在构想一个集中式工作流程，每个开发人员都在他/她的机器上拥有代码的本地副本。我们宁愿将GitHub Enterprise用于共享存储库，而不是在GitHub上托管代码。

我不太清楚从哪里开始正确地进行此设置。我一直在看视频和阅读教程，但似乎没有一个直接适用于我们想要做的事情。 GIT是否适用于我们想要的设置类型？另外，清理/构建如何使用Eclipse和本地副本与共享存储库一起工作？

答案

首先，看看this video。

其次，如果你正在使用Eclipse，你会想要使用EGit。非常详细的教程here。

第三，不要把自己扔在GIT上。在某些时候考虑SVN（在GIT上记录之后）。也许中央版本控制系统比分布式版本控制系统更好。

编辑：

哦，顺便说一下...这个主题有一个很长的，很有名的Q＆A right here。祝你好运。

第二次编辑：

至于SVN，here你有一个关于Subversive的简单教程，而here你可以找到完整的面对面的Subversive文档。

另一答案

您现在有需求，但您的需求会发生变化。保存自己后来从SVN转移到Git并从Git开始的头痛。以下是Git优于Subversion的原因：

1. 速度 - Git速度更快
2. 磁盘空间 - Git历史很小。大部分时间它占用SVN历史空间的1/10。
3. 没有服务器 - DVCS不允许管理员，您可以完全跳过集中式服务器。您的中央存储库可以只是网络共享上的文件。
4. 完整性 - 数据损坏非常容易检测和纠正。
5. 快照历史记录 - 为每个版本快照整个项目。没有与版本混合和匹配的路径。
6. 开源依赖项 - 您可能想要使用的大多数项目都在Github上。您可以轻松地添加子模块和版本的依赖项。
7. 功率： git bisect - 找到快速引入错误的位置 rerere - 重用你如何修复冲突，如果他们再次出现 支持任何工作流程 适当的三方合并 - 这将在未来节省大量的麻烦 变基 - 即使有人合并，你也可以保持你的历史线性

我的最后一点非常重要。您刚刚开始使用源代码管理。从最佳选择开始。您处在一个您最不了解自己需求的地方。你认为你现在不需要的东西，你需要稍后 - 保证。

另一答案

我会create a git repository on the shared drive，你根本不需要像github这样的服务器。设置完成后，开发人员可以从共享驱动器克隆到本地计算机，并在完成后将更改推回。

每个开发人员最终都会得到代码的本地副本，他们拥有自己的构建环境，而不再是彼此的方式。

从一个示例项目开始，只包含一些文件并使用它，因为您需要获得一些版本控制系统的经验。还要学习git命令行工具（对于windows使用msysgit），因为互联网上的大多数例子都是为那些写的。有关git的更多信息，请务必阅读免费的git书：http://git-scm.com/book

另请参阅此question关于在Windows共享中使用git：How to git clone a repo in windows from other pc within the LAN?

另一答案

EGIT for eclipse是在你的eclipse项目环境中集成git的好人。

此外，如果你在Windows上，你可以下载Github for Windows，它非常简单，有效使用。

另一答案

GIT当然是首选的方式，并与Eclipse IDE很好地集成。但是你也可以使用Subversion，因为你想拥有的只是用户机器上的本地代码副本（称之为subversion分支）。我说首选的方式是因为GIT过于灵活：离线提交，代码体的完整副本而不仅仅是分支等....列表太长了。

如您所述，您也可以使用github。粗略地说，步骤如下：

1. 只需注册即可
2. 创建一个存储库。
3. 获取存储库的链接并将其指向Eclipse中的新git存储库
4. 推送你的代码。承诺吧。

您将在github中拥有您的代码文件。如果你在Eclipse中安装了Git，这将有效。我相信Eclipse Juno已经安装了EGit（Git插件）

要解决构建问题，可以使用像Jenkins这样的一些持续集成工具。这也可以设置为Eclipse插件。

另一答案

正如一些人已经指出的那样，提问

使用GIT的最佳方式是什么？

在您的情况下（零SCM体验）最佳和公平的无偏见答案将是

根本不要使用Git！

与“为什么Git比Subversion更好？”相反。你也可以阅读的主题（快速召回的一些子集）

• GIT - What gotchas should newcomers to version control be aware of?
• What does SVN do better than git?
• What are pre-requisites for learning & understanding Git?

并查看git tag下的其他主题与Git-boys的多个哀悼。

虽然Subversion是一个相当不错的选择（无论如何都有一些优势：即使你认为开发是线性的，你也可能属于“Merge Hell”：一些分支可能并且必须发生，进入“Refactoring Nightmare”并出现着名的“Tree conflict”错误...）你可以考虑“可用作颠覆和强大而不是Git”的替代方案（即使你只使用所需的小部分或整体能力）： - Mercurial“软件工程师为软件工程师制作的具有人性化的DVCS” ，不适合时髦的家伙“。

• MercurialEclipse是Eclipse请求的答案（在Aragost recommendation Mercurial用户信任）
• TortoiseHG是用户友好的跨平台GUI，适用于Eclipse之外的所有Mercurial需求
• 与同等的Git服务器相比，Mercurial服务器需要更少的头痛（特别是“在Windows下”）
• Mercurial真正的专家很容易找到（而Git-boys更有趣 - 喜欢狂热少年的俱乐部）