Best Practices for using Git with Intellij Idea

In a nutshell: what are best practices for using Intellij Idea (9) 开发者_C百科and Git?

Context

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

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.

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

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"?

-Is it a good idea to use Autostash?

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

-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.

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

Thanks

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.

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 much better 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):

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

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

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).

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?

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

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 CAUTION if 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.

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

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

• 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.)

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

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

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 push your 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).

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

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

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).

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