我的伙伴拒绝在IntelliJ中设置GitHub，因为他觉得GUI太不熟悉，更喜欢通过命令行执行所有GitHub请求
我也会这样。
我们应该以同样的方式使用GitHub吗？或者我们正在做的方式很好。
使用不同的工具是很好的，一般来说，一个人甚至应该能够在一天中随意地在工作目录上使用git CLI和（胜任的）git GUI/IDE之间来回切换。
有人有过这样的经验吗？
我是一个使用git的双人团队（但不是GitHub --但这不重要）。我在Mac上使用CLI，而我的队友在Windows上使用TortoiseGit。（我想他也通过Netbeans做一些git的东西）。我们最初在解决Mac vs Windows vs Unix问题时遇到了一些问题（与CLI vs GUI无关），但我们在使用不同的UI访问git时没有遇到任何问题。
我最大的困难是向我的队友解释如何做一些复杂的事情，比如复杂的变基，因为必须将CLI命令“翻译”成TortoiseGit GUI菜单项/对话框选项，特别是当UI试图通过以“用户友好”的名称列出命令而不是它们的git命令来“提供帮助”时。
我们都没有太多的GitHub经验
[肥皂箱]
我认为在刚开始使用git的时候，精通git CLI有一个真实的的优势。我认为使用CLI可以为git知识打下良好的基础，并帮助开发一个良好的git工作模式。GUI，尤其是IDE中的GUI，我倾向于抽象/概括版本控制系统（VCS）-尝试简化UI并在不同的VCS之间保持一致。如果你使用多个VCS和/或不需要非常深入地学习VCS，这是很好的，但如果你想成为git大师，这是不好的。
当你熟练掌握git并对git范式有了一个坚实的心智模型之后，你就可以随意使用GUI了--到那时，你将把GUI命令Map到你已经建立的git心智模型上，而不是试图从一个稀释的UI中建立一个git如何工作的心智模型。
[/肥皂箱]

你用来处理git仓库的工具不会影响你的协作者的工作流程--只要你的工具和服务器运行正常。
像IntelliJ这样的多语言IDE倾向于为每个项目提供一些配置，以了解该项目是否启用了git功能。如果您的IDE为文件着色以告诉您它们的git状态，那么您启用了这些功能。如果您的队友没有启用这些功能，那么他禁用了这些功能。
您可能没有对这些IDE特定的配置进行版本控制，所以您有不同的设置，但这对于协作来说完全没有问题。

如果提交的代码符合您同意的标准，它是所有的计数：）
在使用任何工具（IDE）之前，先学习一下材料（CLI）。它的价值有多个原因。
1.迫使您了解它是什么以及它可以做什么
1.让你去做你工作中必要的步骤（省略你不需要的）
1.使您能够决定哪种工具或程序能提高您的工作效率
如果你用X更有效率，那就太好了！分享为什么它对你有用，让别人来决定它是否对他们有用。如果你发现自己声称X是最好的，别人可以更快地提交-重新评估。如果你出于任何原因不得不使用X工具，它将成为你的限制（例外：该工具变成事实上的标准）。
如果你看到你的未跟踪/新文件是彩色的，那对你很好！但也许你的伴侣不在乎。也许你给他看Ctrl + V (+4)后他会在乎。更可怕的前景是你们两个都只知道工具X。
有了自由就有了责任。使用Git，这是相当简单的，因为在Atlassian上有很棒的社区和优秀的教程。

我认为IDE最擅长解决合并冲突和大多数命令。最常见的问题发生在人们试图解决合并冲突/用父master/develop分支更新feature分支时。IDE有时会混淆rebase和merge的决定。git命令行明确建议使用merge和rebase=false。而iDE显示了一些按钮来合并/rebase和人们只是点击一些东西，看到一些意想不到的行为和失去信心。x1c 0d1x