It's a lot of work to do this but it's worth it.

For observable work, do these things: Be the authoritative source for your own data,
Pass by reference not by value,
Know the difference between structured and unstructured data,
Create and adopt disciplined naming conventions,
Push your data to the widest appropriate scope,
Participate in pub/sub networks as both a publisher and a subscriber,
Reuse components and services

"You see, Feature Toggling is not just a different way to achieve feature branching. It is an architectural choice that, sure, helps with maintaining mainline development but the power is that it hands back control of what features should be enabled and when to the business. And it is there, ready for you to harness. No extra steps required. As awesome as Git is, you just cannot compete with something that allows you to not only control what features go into a release but what features are live at any one time."

Branch by abstraction, some discussion about feature toggles and other alternatives.

Some shots of how cartoonist Virgil Partch worked, from concept to finish. via http://tumblr.austinkleon.com

Junio on how to maintain topic branches, bug fixes, and a workflow to avoid missing related fixes when merging between branches.

Martin Krafft explains how to do a clean git-svn import, rebase a git history on top of it, and convert patches to branches; with commands you can copy-paste. Plus a short bonus lesson on merging. In a Debian packaging context but still useful elsewhere.

A very detailed walkthrough from Martin Krafft on how to maintain a Debian package in git, tracking a git upstream. Includes discussion of branch usage showing examples for topics and integration, with commands you can run. Also the use of tags. Useful even for non-Debian work! From 2007; some git commands may have changed.

Nice article on how to manage branches that have some changes that need to get merged back to master, and some that don't. These can be release branches or they can be branches targeted at specific customers.

A nice post on different git workflows. The best part is about branch naming: "Using ‘origin’ as the name of your remote and ‘master’ as the name of your main branch is just the default settings git gives you. Neither name is magic. So, I renamed ‘origin’ to ‘github’ in .git/config to be explicit about where the code is going. Then, I created a new branch ‘development’ to reflect the code that is under the mainline of development."

Code review tool from Google! Compare to ReviewBoard. Appears to provide also a public service (codereview.appspot.com).

How to manage git commits across multiple repositories, etc.

An excellent description of basic workflow and explanation of git's index.

How to use "git rebase" with topic branches and the relative workflows used by leaf-developers versus subsystem maintainers and core integrators. The thoughts of Linus himself.

VMware's tool for managing code reviews: supposedly supports Mercurial, Git, p4, CVS, SVN... what more could you need?

Presentations from names like David Riecks (ControlledVocabulary) and Peter Krogh (DAM).

Automating some of the things done by ImageIngester or PhotoMechanic using OS X folder actions, automator and exiftool.

Tagging and metadata tagging

One person's 2007 photo workflow: bridge->dng->ivmp/lr->ps

Uses Mac's Automator to power through tasks in iView MediaPro.

What /. readers think about collaborating and tools for collaborating...

Discussion for a common math/science platform.

dga and feamster's fledgling collaborative project to manage data workflows for measurement studies, perhaps one day to be integrated with emulab.

Covers white balance, raw workflow, composition, highlight recovery, more...

Compares C1, Bibble, RSE, Photoshop CS, BreezeBrowser and Canon DPP.

nice write-up of how to organize your workflow for research and what tools the author uses