首先，如果这不是提出这个冗长问题的正确位置，请道歉。到目前为止，我做了很多研究，现在处于被信息压垮的阶段，而且变得更加困惑。
我在一个刚刚与IT领域合并的部门工作。这个问题的意义，以及这个问题的原因，是我被告知我们需要开始使用Git进行版本控制。这一切都很好，但我们似乎有很多类型的Git可用，我正在努力确定哪个最适合我们团队的需求。主要问题是我们开发的系统是一个封闭的生态系统，有自己的编辑器。因此，对于Git来说，它意味着将开发导出到文本文件，我们可以这样做，但我们不能使用这些文本文件。
我们可以访问：
Git Enterprise，Git Bash，Git stash（和bitbucket一样？）和Git Desktop（我认为）
我们做什么：
该公司拥有会计/税务系统，并为客户提供管理服务。通过该系统，我们向包含各种信息的客户提供报告。我们的工作是开发这些报告并根据需要进行更新。
我们如何做到：
我们使用提供的系统和附带的GUI，在专有（有些人可能会说是古老！）系统上开发这些报告。这些报告的代码备份为文本文件。正是这些文本文件我们将寻求版本控制。 目前我们有各种各样的区域。我们有“实时”区域，这是在开发和测试完成后将报告复制到的区域。然后我们有许多“项目”区域，它作为现场区域的副本开始，是我们开发和测试新/修改报告的地方。 报告开发完成后，我们将新的/修订的报告从项目区域复制到实际区域。
问题：
1）我真的很难想象使用Git如何工作。我认为我们将使用它的方式是，
将项目区域视为分支
在新分支
然后当开发完成后，与项目区域中的主版本合并
然后（不确定此部分）每天导出项目区域中的文件，
找到任何已更改的内容（即已与dev分支合并）
然后将所有更改合并到实时报告备份
将所有已更改的备份导入实时区域
2）使用哪种Git工具？我们需要能够在某种程度上自动化这个过程，需要相对简单的使用和在各个位置进行协作（这就是为什么Git被推动我想象的原因）
从我最初的调查来看，我不确定最好的入门方式。我对版本控制软件的唯一体验是SVN，当我还是学生时，我简单地将其用作模块的一部分。
我不期待从这里一步一步的指导，只是一些建议/建议哪个界面可能最适合我们的需求。甚至可能还有一些关于在何处可以找到良好资源的指针。
非常感谢任何需要时间提供建议的人。非常感谢！
答案 0 :(得分：0)
这是一个有点开放的问题，但我会试一试。我将首先解决Git工具的问题;在“工具”列表中，它们并非完全属于同一类别。
Git Enterprise：这是一个git存储库，并托管CI / CD（持续集成/交付）管道。这意味着它将存储您的代码，并使您能够在合并分支机构，私有存储库，直接部署到AWS（Amazon Web Services），全天候支持等等之前运行测试套件。基本上是一个企业瑞士军刀开发。这与Gitlab和Bitbucket相似。
Git Bash：除非有我不知道的产品，否则这只是指通过bash终端使用Git系统（Linux的常用命令行界面）。
Git Stash：同样，除非有一些我不知道的东西，否则这不是一个工具，而是一个使用Git时可用的命令。假设您在分支上进行了一些更改，并希望提交一个部分，但将其他部分保留在本地且不在提交之外。 Git stash允许您将更改/文件放入一堆未提交的临时项目中，并可以在以后删除并放回。
Git Desktop：这将是GUI桌面客户端，它是Github或Github Enterprise等存储库的接口，就像'git bash'是命令行界面一样。
有点奇怪的是，你要备份代码的文本副本，而不是实际的代码文件本身;特别是如果你正在使用Git。除非你使用一些非常模糊的语言，其中代码存储为二进制文件而不是直接文本，所以任何代码文件都可以与Git一起使用。另外，除非您运行自己的私有Git仓库，否则备份通常由您选择托管的任何人（Github，Gitlab等）处理。即使您运行自己的Git仓库/服务器并担心备份，也可以设置一个系统来镜像仓库，或者为服务器硬盘驱动器使用RAID 1或类似的配置。
至于如何使用Git，您应该阅读的内容是“分支策略”（https://www.atlassian.com/git/tutorials/comparing-workflows）。
如果您不需要支持多个版本，功能标志等，那么这里是一个（相当简单）的模型：
git up确保您拥有最新的主副本。git checkout -b NewBranchName git add *暂存这些更改以添加全部，或git add ...指定多个文件名。 “分阶段”更改将在您提交时正式添加。git status检查已添加/修改/删除的文件。 git commit -m "Commit title" -m "Fixed bug xyz"提交您的更改，并提供您所更改内容的标题和信息说明（您可以使用git log查看每个分支的提交历史记录）。这些更改现在正式在您的分支中，但仅限于本地。git push ...将您的更改推送到远程存储库。请注意，根据您正在开发的应用程序类型以及如何进行测试，这可能不合适。
最后一个想法：从我（尽管很短）的经验来看，最好不要为同一个项目拥有多个长寿分支。由于新提交它们分歧的时间越长，将它们合并在一起就越困难。如果可能的话，进行小型提交，并在几天内甚至每天测试和合并您的功能分支。这使得合并更容易查看，合并冲突（两个人修改了相同的代码段）更容易解决，并且在引入错误时更容易隔离。
希望澄清一些问题。祝你好运！
答案 1 :(得分：0)
几十年来，我一直使用很多的版本控制系统，Git赢得了胜利。但它并非没有问题。以下是一些一般性建议：
许多人试图通过过于简单的工作流程来扫描地毯下的版本控制。他们知道如何提交，也许是差异，以及关于它的问题。他们可能会认为版本控制只是一个乏味的备份工具。
版本控制是如此之多。它与您的代码的测试，审核，调试和理解密切相关。它会影响您与他人合作的方式。它可以帮助你摆脱错误。通过良好的工作流程，许多人可以做很多事情，而不是互相帮助。
Git学习曲线陡峭，界面糟糕，但值得攀登。 Git非常强大，也许功能太强大，学习如何使用它是值得的。
Git非常灵活，您可以使其像您习惯的版本控制系统一样工作。唐＆＃39;吨
Git是Git，有一种非常独特的做事方式。最糟糕的错误之一是没有学习Git是如何工作的，而是试图像对待SVN一样对待它。 git add不像svn add那样有效，git commit不像svn commit那样有效。
通常情况下，软件具有良好的界面，您不必关心它是如何工作的。不幸的是，Git的界面非常糟糕，它对你的工作方式很有帮助。例如，git log默认情况下会显示历史的线性视图;这往往是制造和混乱的源头。
通过学习Git存储库的结构以及命令实际执行的内容，而不是他们所说的内容，可以省去很多挫折。这将允许您通过可视化存储库的当前状态以及如何将其更改为您想要的内容来解决问题。
对于界面的所有复杂性，Git引人注目的简单。可能需要理解四个关键事项：图形，暂存区域，分支标签以及提交ID的作用。它们都很容易可视化。我就此发表了演讲，here's an old version to get you started以及a cheat sheet that might help make sense of the interface。
Gitless是一个改进Git界面的Git客户端，通过专注于基本工作流而不是那些特殊情况的广泛来降低其复杂性。它使学习曲线不再是砖墙而是更陡峭的攀登。
它仍然是Git，同一个存储库可以与Gitless或Git互换使用，所以没有风险可以让它一拍。