I use and highly recommend Gerrit. http://code.google.com/p/gerrit/ Having a code review-based workflow has shifted my team from never talking with each other and writing silos of bad code to talking with each other every day and actively working to improve things. It's probably the best thing we've ever done.
Is there a graphical tool (along the lines of TortoiseSVN) that you can use to do all this?
The added hassle of memorizing shell commands (and opening a command prompt every time you want to commit) are just not worth any incremental benefit that Git might provide. I'm happy using SVN because it's got good tools. Surely there's an equivalent for Git?
--no-ff doesn't get rid of the individual commits, it just guarantees that a merge commit gets created as well, so it's easy to see what branch was merged in. If you don't use it and the commits you're merging in can be applied via fast forward, it skips creating the merge commit.
Tangential, but any suggestions for educating a dev team used to another VCS? (In my case, Perforce, but I'm sure e.g. svn->git advice will be useful for someone.)
I've used both git & p4 for a while and know their ins & outs, but would love to know if anybody has any suggestions for the crossover. My X-importing-to-Y experience has been limited to svn-to-git, svn-to-hg, and hg-to-git.
I made some success by showing off git-svn in the environments/places where they were still using svn. I would show off by using many local branches, by doing things like fixing bugs in another branch right away, test other developers' commits in other branches to see if they really work, or basically things that are hard to do with svn. They still get to use their svn repos as the "origin" but they meet the flexibility of git.
I dare you to implement a compiler with only stuff invented since January 6, 2010. Or do basically anything (including eat). Eventually, we'll pity you and bring you antibiotics and parsing algorithms.
Best practices change a lot more slowly than the emergence of new technologies. For the good reason that to determine something is a best practice takes time and finding something even better takes even more time. When considering core/base technologies it's usually safe to give it a lot more than ten months before dismissing it and even in that case only in the presence of something known that could improve on it.
Replacing your best practices/processes every couple months to keep up with the latest trends is a recipe for disaster in any multi-person development environment and change breeds confusion.
That said this setup won't work for everyone nor does the author claim it should do. It's another possible tool for your belt to consider depending on your work and the team you're working with.
I guess the to short version is don't be so quick to dismiss things based off age(or lack thereof in this case) unless you can dismiss it with a proven replacement.
personally how I do things is constantly changing. Usually in small increments but I am always looking for new and better methods. Many will just just be used for a short period.
You should not however be so quick in concluding that I said to dismiss the article. I am nearly bringing attention to the fact that it is nearly a year old and to consider it while making your own evaluation of the article.
Some things I've found are best to keep fairly stable for longer periods of time. Branching policy with git is one of these. I'm not sure of your experiences with managing development teams using git but from mine I've found setting a branching policy(this one actually) and making sure people stick to it is the best way to minimize confusion and keep people on track.
Side note: I think the reason your previous comments were down voted wasn't your concern about the age of the article so much as your lack of a better alternative. If you could say "This was from Jan and this has been shown to be better" people would probably be posting stories about your new technique. To just say it is 10 months old though adds nothing to the conversation.