On Wed, Feb 9, 2011 at 1:57 PM, Fabrizio Giudici < [email protected]> wrote:
> > 2. For refactoring and renames, I use the IDE (NetBeans) that does all for > me. Yes, with some occasional bug (talking of 6.9), but no dramatic ones. > One of the many things I like about git is that it doesn't need any IDE support to work correctly. SVN and P4 do need that to some extent (e.g. you need to `p4 edit` a file before you can modify it). Git doesn't care: modify, rename, delete, do whatever you have to do and do it wherever you like (shell, IDE, emacs, etc..) and when you are ready to commit/push, git will just look at your file system and it will be able to guess what you did (most of the time). > 3. For what concerns rebase, I must confess I've not completely understood > what it is (also after reading Reiner's post). I read "rewriting history"... > how much is it different from the "squash commit" technique described by > Fowler: http://martinfowler.com/bliki/MercurialSquashCommit.html? > Rebasing (just like Git's index) is the kind of concept that seems quite confusing at first, but when you get it, it's the most natural thing in the world. My attempt at describing it: most source control systems don't make any distinction between public and private commits. As soon as you commit something, it will be visible by everyone. With the index and rebasing, you can actually separate the two. While you are working on a problem, you can commit as often as you want, even when your code doesn't even compile or doesn't pass the tests. It doesn't matter since you will get a chance to modify these commits before pushing them to a public repository. This allows you to work very incrementally. Once you're happy with your change, you get a chance to review all your private commits and merge them into one (or reorder them, or pretty much whatever). Since you have commit messages for each of them, you also get a pretty good idea of what you did and you can replace all these small messages with a bigger one that is more descriptive while removing the little implementation details that only you cared about during development. So you turn these n little commits into a bigger one and you push it. It becomes a second nature once you get used to this kind of flow. And then, as you become more comfortable, you become more precise with your rebases. For example, imagine you have 5 commits that mix up the fixes to two different bugs. So you rebase and you turn commits 1, 3 and 5 into one for bug 1 and commits 2 and 4 for bug 2. Rebase allows you to do pretty much whatever you do with your history. Just a few examples off the top of my head. Git is a very exciting technology to work with once you start understanding it. -- Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
