logo标签列表

对于小型内部团队来说，使用Git是否有意义？

gitsvn
11

在我看来，Git是为大型开源项目设计的，具有大量开发者和团队。

我想知道对于小团队（＜10人）和内部项目（组织内部）来说，Git是否值得使用。我理解拥有存储库的本地副本会带来明显的性能优势（尽管在组织内部的存储库不太重要...）。

你是否仍然推荐使用Git（以及伴随而来的复杂性），并说明原因？

1
请提高您的回答率。 - Dan Abramov
可能是 https://dev59.com/y3VC5IYBdhLWcg3wjyDu 的重复问题。 - Jonathan Hall
@Flimzy：我不这么认为，因为Git非常具体。“我应该在小团队项目中使用Git”和“我应该使用版本控制”是不同的问题。 - Dan Abramov
2
对我来说，这似乎是一个客观、建设性的问题。有没有Git的功能使其不适合小型内部团队？如果你不懂Git，回答这个问题会很困难。你需要问一个知道Git的人。嘿！我们应该为此制作一个网站！ - Charlie Flowers
7个回答
17

Git并不是非常复杂，但它非常强大和精确。我无论是在个人项目还是10万人的项目中都不会使用其他工具。我是认真的。

我知道为什么人们说它很复杂，但那完全是被夸大了。要做所有需要做的事情，你可能最多需要使用10个命令，并且你不需要理解这些10个命令的每个选项...只需要几个“食谱”。

你确实需要理解一些关于Git 内部运作方式的知识。但这并不是因为Git很复杂——而是因为Git与众不同。你可以花一两天的时间研究这些信息，然后就可以掌握它了。

请原谅我的粗鲁，但Git使文件系统成为了你的“婊子”。你可以随意地在软件项目的“备用现实”之间切换。一旦你了解了这个工具的来源，你将对组成你的软件的位和字符拥有完全、几乎是神一样的控制能力。对于软件开发人员来说，几乎没有其他如此强大的工具。

是的，朋友，我推荐使用Git。试试吧。你会非常高兴的。祝好运。

5

Git对于大型和小型团队都有意义。是的，Git很复杂，但这并不意味着您总是需要处理这种复杂性。我每天都使用Git，而且我很少使用除以下命令之外的任何其他命令：

git branch # To remind myself what features I'm working on.
git checkout <name_of_branch> # To switch to whatever I want to work on.
git checkout -b <name_of_new_feature> # To start work on a new branch
git add <name_of_file> # To add it to the list of tracked files.
git commit -m <commit_message> # To checkpoint my work.
git merge <name_of_branch> # To integrate changes back to trunk.
git branch -d <name_of_branch> # To delete a branch after it has been merged.

在日常工作中，你只需要记住几个命令即可。对于任何更复杂的操作，你总是可以在文档中查找。

我真正喜欢 git 的一点是，即使工作还没有准备好提交到代码库中，你也可以将其保存为一个版本控制的检查点。例如，我可能会在实际向其他开发人员展示之前，在本地使用 "git commit" 多次。这大大增加了我对修改代码的信心；我可以进行实验，而不必担心我的当前工作会丢失 - 如果出现问题，我总是可以恢复到安全版本。这在 SVN 中是不可能的，因为任何提交都会在主代码库中显示。

你所说的“提交到存储库”是什么意思？如果Git没有中央存储库，那你所说的存储库是哪个？Git很令人困惑。 - Bruno Santos
1
@BrunoSantos 即使它是分布式的，一个项目或组织通常会有一个单一的代码库来反映真实、官方的代码状态。无论如何，当我说“提交到代码库”时，我的意思是 - 在Git术语中 - 您可以进行本地提交，而不必将这些更改推送到远程代码库（无论它是官方代码库还是其他远程代码库），而在其他版本控制机制中，则必须使用单独的工具来处理本地版本控制。 - Michael Aaron Safyan
4

我个人在一个只有1个人的项目中使用Git，也在另一个由5个成员组成的项目中使用。

以下是我个人喜欢Git的原因：

  • 分支和合并非常方便；
  • 可以建立多个仓库来积累不同种类的更改（对于Web项目非常有用）；
  • 它可以通过HTTP、SSH等方式工作，(无需考虑如何连接)；
  • 一旦你习惯了提交-直到好为止-然后推送的工作流程，你就不能回头了。

对于聪明的团队而言，它的好处更加明显：

  • 一个人可以在一个分支上工作数周，而不必担心以后需要解决100个冲突问题；
  • 分布式工作流程更加合理，并且还可以整合代码审查进入您的流程中。

然而，如果你的团队很愚蠢（这有时可能是真的），或者对Git有偏见，我强烈建议不要使用它，因为它需要一定的努力和程序员的好奇心去学习，而且并不是世界上每个人都想分支、合并、使用分布式工作流程或Git所提供的其他任何东西。

1
很简单：它非常漂亮地完成了它应该做的事情：版本控制。
没有多余，也没有少了。
它与我的集成开发环境配合得很好，完美地合并了团队的编辑，并且我可以随时查看旧代码。
1

是的，因为与 svn 相比，更改跟踪的工作方式导致较少的冲突（在大型多步合并中）。

是的，因为你可以在工作时进行小的本地提交，然后将完整的工作更改推送到主存储库。当你执行推送操作时，所有微小的提交都会被推送。

是的，因为当你从主存储库拉取时，它不会立即合并，而是将拉取的内容放在分支中。当你做出较大的更改并希望在某些计算机上延迟更新时，这很完美。

1

对于个人项目，我更喜欢使用 git 而不是 svn。统一使用相同的工具更为方便，而且同时维护 git 和 svn 存储库对我来说似乎毫无意义。

1

我会说是的。

即使是在我自己的工作中，我倾向于使用git，因为它拥有很多有用的功能。不需要通过网络（即使是内部网络）进行除了推送和拉取之外的所有操作，这在长期来看可以节省大量时间。像切换不同分支这样的事情都是在本地进行的，就像阅读日志一样。

需要注意的是，即使git是分布式的，你仍然可以有集中的仓库，所有人都将代码推送到和拉取自该仓库。但这只是约定上的一个中央仓库。

而且，便捷地创建分支也是一个优势。你可以轻松地创建一个主题分支，在其中实现一些小的功能，并将其合并回开发分支中。

有关成功的分支策略，请参考git flow。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接