将 Git 与 Intellij Idea 结合使用的最佳实践

Best Practices for using Git with Intellij Idea

提问by user331465

In a nutshell: what are best practices for using Intellij Idea (9) and Git?

简而言之：使用 Intellij Idea (9) 和 Git 的最佳实践是什么？

Context

语境

We recently upgraded to Intellij idea version 9 and have started to use Git for a new feature on existing project.

我们最近升级到 Intellij idea 版本 9，并开始使用 Git 来为现有项目提供新功能。

We largely use git command line to learn the tool better. But we thought we'd pick the hive-mind to find out what are best practices for git with idea.

我们主要使用 git 命令行来更好地学习该工具。但是我们认为我们会选择蜂巢思维来找出 git 的最佳实践和想法。

The Idea UI is similar for both CVS and Git, yet the underlying implementations differ a bit.

CVS 和 Git 的 Idea UI 相似，但底层实现略有不同。

Example Questions

示例问题

For example: -With CVS, when we had multiple release of a product, each of us would have a local copy of the 1-0, 2-0, 3-0, etc. branches , each with its own Intellij files (i.e. .ipr, .iws, etc.). The "git way" seems to have one project and use 'git branch' to switch branches. This is fine, but it creates huge overhead for idea (as it has to reload each changed file, including checked-in jars) when you change branches. So: do you still have a separate project (with .git) for each "major release" or have one project and use "git branch"?

例如： - 使用 CVS，当我们有多个产品发布时，我们每个人都会有 1-0、2-0、3-0 等分支的本地副本，每个分支都有自己的 Intellij 文件（即.ipr、.iws 等）。“git方式”似乎有一个项目，并使用“git branch”来切换分支。这很好，但是当您更改分支时，它会为创意带来巨大的开销（因为它必须重新加载每个更改的文件，包括签入的 jar）。那么：对于每个“主要版本”，您是否仍然有一个单独的项目（使用 .git），或者有一个项目并使用“git branch”？

-Is it a good idea to use Autostash?

- 使用 Autostash 是个好主意吗？

-Do you automatically add each modification to your git commit? or use "git add" later?

- 你会自动将每个修改添加到你的 git commit 中吗？或稍后使用“git add”？

-Do you rebase?

- 你变基了吗？

-Best way to merge?

- 合并的最佳方式？

-Any other hints/tips/what-works-for-you,etc.

- 任何其他提示/技巧/对你有用的东西等。

Final Comments

最终评论

We still "think in cvs" so part of this is getting used to git; part is getting used to Idea's Ui for git.

我们仍然“在 cvs 中思考”，所以其中一部分是习惯 git；一部分正在习惯 Idea 的 git 用户界面。

These are fairly rudimentary questions as we still use the comand line primarily. Also I've heard idea 10 has better/stronger/faster git integration tools

这些是相当基本的问题，因为我们仍然主要使用命令行。另外我听说idea 10有更好/更强/更快的git集成工具

Thanks

谢谢

采纳答案by user331465

Here's what we've found after several weeks of Git/Idea. I've made this a community wiki. Please throw in your 2 kronor/centimos/pfennings/cents.

这是我们在使用 Git/Idea 几周后发现的结果。我已经把它变成了一个社区维基。请投入您的 2 克朗/厘莫/芬宁/美分。

Note: I'm answering my own question because I sought those easy-use bullet points.

注意：我正在回答我自己的问题，因为我寻求那些易于使用的要点。

Presupposition

前提

Idea is great tool. No one here is complaining. Just observing.

想法是一个很好的工具。这里没有人抱怨。观察而已。

Best Practices

最佳实践

• At this point (9.0.3) Git with Idea is just plain harder to use than SVN with Idea. Part stems from the complexity of Git (vs SVN), partly because Idea's tools don't do everything in the git world.

• Thus you will need to use the command line

• Idea's merge tool works muchbetter than command line merging or even using mergetool (using meld or mergetool). The reason: you have much more freedeom to work in the 'idea environment' rather than fixe one lint at a time.

• Remember to synchronize in Idea (ctrl-alt-y) when you update the working tree from the command line

• Watching the Git Console to learn idea's git tricks; idea executes git commands there.( Version Control view, Console tab):

• 在这一点上（9.0.3），带有 Idea 的 Git 比带有 Idea 的 SVN 更难使用。部分源于 Git（vs SVN）的复杂性，部分是因为 Idea 的工具并不能在 git 世界中做所有事情。

• 因此，您将需要使用命令行

• Idea的合并工具比命令行合并甚至使用mergetool（使用meld或mergetool）要好得多。原因是：您有更多的自由在“想法环境”中工作，而不是一次修复一个 lint。

• 从命令行更新工作树时记得在 Idea (ctrl-alt-y) 中同步

• 观看 Git 控制台，学习idea 的 git 技巧；idea 在那里执行 git 命令。（版本控制视图，控制台选项卡）：

example:

例子：

13:30:58.234: git log -M --follow --name-only --pretty=format:%H%x00%ct%x00%an%x20%x3C%ae%x3E%x00%cn%x20%x3C%ce%x3E%x00%s%n%n%b%x00 --encoding=UTF-8 -- src/jsp/workspaces/include/edit.jsp
13:31:02.437: cd J:\projects\PE-GIT\pe
13:31:02.437: git annotate -p -l -t -M HEAD -- src/jsp/workspaces/include/edit.jsp

• Unfortunately Idea does not have good tools for "merging conflicts in upstream commits" in 9.0.3

• 不幸的是，Idea 在 9.0.3 中没有用于“合并上游提交中的冲突”的好工具

Example:

例子：

• Alice does work, commits (locally) file A, commits file B, commits file C
• Bob does work, commits file C, commits file D, commits file E
• Alice pushes her changes
• Bob Pulls his changes

• Alice 工作，提交（本地）文件 A，提交文件 B，提交文件 C
• Bob 工作，提交文件 C，提交文件 D，提交文件 E
• 爱丽丝推动她的变化
• 鲍勃拉他的变化

Coming from CVS/SVN, I expected Ideas handy diffing tool to pop up. No. Instead git/idea throw up a red flag, I usually end up using "git mergetool" (meld od on linux, tortoiesmerge on windows).

来自 CVS/SVN，我希望 Ideas 方便的差异工具会弹出。不。相反，git/idea 会抛出一个危险信号，我通常最终使用“git mergetool”（linux 上的 meld od，windows 上的 tortoiesmerge）。

Note: Perhaps Idea provides a better way. Please set me straight. Note to the motivated: can you set up .gitconfig to use Idea's diffing tool?

注意：也许 Idea 提供了更好的方法。请让我直截了当。请注意：您可以设置 .gitconfig 以使用 Idea 的差异工具吗？

Stashing

藏匿

• Ideas "Shelve" functionality duplicates "Git Stash". Both seem similar. Both use patches. You probably want to use one or the other. I haven't figured out the advantage of one or the other

• 想法“搁置”功能复制“Git Stash”。两者看起来很相似。两者都使用补丁。您可能想使用其中之一。我还没有弄清楚其中一个的优势

Big Old Projects

大老项目

• If you're working on a decade old project recently migrated to Git, with jar files checked into the scm (i.e. previously checked into CVS/SVN, where log4j-1.0.jar is in BRANCH-2-0 and the mainline has log4j-9.0.jar ), PROCEED WITH CAUTIONif you want to checkout "version 2.0" of your project. Idea needs to unload all the "head" jars and reload the jars-checked-in-at-2.0. This takes for-ever.

• 如果您正在处理一个最近迁移到 Git 的十年前项目，将 jar 文件签入 scm（即之前签入 CVS/SVN，其中 log4j-1.0.jar 在 BRANCH-2-0 中，并且主线有 log4j- 9.0.jar），请谨慎操作，如果你想你的项目的结帐“2.0版本”。Idea 需要卸载所有“头部”罐子并重新加载 jars-checked-in-at-2.0。这需要永远。

Other little stuff

其他小东西

• The idea menus/UI still shows "git init..." even though you've already initialized Git. It's confusing, but ignore it.

• You cannot have the same working tree in both Git and CVS/SVN (though the UI may seem to imply so). I/we tried this during an initial "let's try git and still use CVS as a backup plan" phase. It didn't work

• 即使您已经初始化 Git，创意菜单/UI 仍会显示“git init...”。这很令人困惑，但请忽略它。

• 您不能在 Git 和 CVS/SVN 中拥有相同的工作树（尽管 UI 似乎暗示如此）。我/我们在最初的“让我们尝试 git 并仍然使用 CVS 作为备份计划”阶段尝试过这个。它没有用

回答by Benoit Courtine

First, you can many information about git on the free online reference books:

首先，你可以在免费的在线参考书上找到很多关于 git 的信息：

• http://progit.org/
• http://book.git-scm.com/
• http://www-cs-students.stanford.edu/~blynn/gitmagic/

• http://progit.org/
• http://book.git-scm.com/
• http://www-cs-students.stanford.edu/~blynn/gitmagic/

Note: Git "good practices" and workflow are totally independant from the IDE you use. Fortunately, IDEA is a great IDE and most Git usefull functions are well implemented (rebase, stash, etc.)

注意：Git“良好实践”和工作流程完全独立于您使用的 IDE。幸运的是，IDEA 是一个很棒的 IDE，并且大多数 Git 有用的功能都得到了很好的实现（rebase、stash 等）

About your git-flow questions, you are thinking like with centralized VCS.

关于您的 git-flow 问题，您正在考虑集中式 VCS。

Git is a DistributedVersion Control System. So, you have to "think local first".

Git 是一个分布式版本控制系统。所以，你必须“首先考虑本地”。

For commits, It doesn't really matters if you add each file to the index immediately or later, if you commit frequently or not. It is your local work, and you can organize it as you prefer.

对于提交，是否立即或稍后将每个文件添加到索引并不重要，是否经常提交。这是您的本地工作，您可以根据自己的喜好进行组织。

What is important is to have clean commits when you are about to pushyour work (expose it to the others developers).

重要的是在您要推送您的工作（将其暴露给其他开发人员）时进行干净的提交。

When you are about to push, you can correct all your history since the last push (with rebase, for example).

当您即将推送时，您可以更正自上次推送以来的所有历史记录（例如使用 rebase）。

For example (if you forgot to amendprevious commit): - commit "a super function" - commit "oups: forgot a file" - commit "bug correction"

例如（如果你忘记修改之前的提交）： - 提交“一个超级函数” - 提交“oups：忘记文件” - 提交“错误修正”

Before pushing theses 3 commits, you can fusion theses commits, using an interactive rebasewith IDEA. So the 2 last commits will be included in the first.

在推送这 3 个提交之前，您可以使用IDEA的交互式 rebase融合这些提交。所以最后 2 个提交将包含在第一个提交中。

Note: you can modify your history while you have not pushed. After you still can but it is a very bad idea (and if you don't force Git, next push will be refused), since it could destroy your co-workers history (if they have fetched/merged your work).

注意：您可以在未推送的情况下修改历史记录。在你仍然可以但这是一个非常糟糕的主意（如果你不强制 Git，下一次推送将被拒绝），因为它可能会破坏你的同事历史（如果他们已经获取/合并了你的工作）。

About a common Git working flow, I recommand you this good article: http://nvie.com/posts/a-successful-git-branching-model/

关于一个常见的 Git 工作流程，我推荐你这篇好文章：http: //nvie.com/posts/a-successful-git-branching-model/