Allright, so that was a bold title! So far I've found one MAJOR thing, which I will describe in here.
This is not meant as a commercial for git, but I feel myself hitting problems with SVN which git solves perfectly. My experience with othe DVCS are pretty much non-existing, so comments are welcome.
And in general comments are very welcome!
A typical workflow could look something like this:
Me: Create branch for feature - MyFeatureBranch
Me: Do some development - and commits it
Other: Makes correct but breaking changes, merged into trunk!
Me: Does a merge from trunk into my MyFeatureBranch
Me: Commits the changes to MyFeatureBranch merged from trunk
Me: Does some more development - and commits
So this was easy, right? Well yes, but it has a major flaw.
See that point where I commit changes made by Others? Well, that makes ME responsible for someone elses code in MY branch! Lets look at the history:
| Rev | Trunk |
|---|---|
| 0 | Initial commit |
| 1 | Development happens |
| 6 | Merged in changes |
| Rev | MyFeatureBranch |
|---|---|
| 2 | Initial branch-commit |
| 3 | Development happens |
| 7 | Catchup to trunk |
| 8 | More development |
| Rev | ColleaguesFeatureBranch |
|---|---|
| 4 | Initial branch-commit |
| 5 | Development happens |
So the history for my branch clearly states(In messages) that I did a merge from trunk, but the machine probably has no way of knowing what happened.
This is not only ugly, but it also poses a problem for the changes I made. What if my colleague made some changes that revert what I originally did?
To be honest, git solves this problem elegantly with the rebase command. Take my branch and instead of having it based on commit 1 have it being based on commit 6. This eliminates the initial branch commits, and the catchup commits, WONDERFULL!