- Git is generally a better tool than Mercurial (hg) for workflows due to its simpler and more powerful functionality that empowers users. However, the choice of version control tool depends on individual project needs and constraints. - Effective workflows depend more on clear communication of roles and processes rather than rigid definitions. Simple workflows or no explicit workflow may work for small teams, while larger projects require more formal processes. - The key aspects of any workflow are clear branching strategies, code review processes, and ensuring clean separation of stable and unstable code during development.

1. DVCS Workflows
short, assorted, highly opinionated musings
(...about why git is better than hg)

2. Summary:
- You may not need a workflow at all.
- have a workflow, describe it, name roles, refine it, it will take months
- Use the right tool, usually git.
- designate a workflow ninja
- know gitflow, the best flow, but adapt it
- know your merge, know your rebase
- do bold moves, you will confuse everyone any way

3. I have not seen commercial application of a decentralized flow.
Are there benefits of a non-centralized flow?
Are there use cases a non-centralized flow?
Distributed has your back covered? Don't delete master (too often)
Distributed flows? Centralized flows.
Who cares about many remotes.

4. - well-known
- successful
- overhyped
- will it fit your release cycle?
nvie's successful branching model and
derivatives

5. - size of the team
- remote or office team?
- no workflow is a workflow (unless you're mad)
- What is the role of a workflow? Muß Ordnung sein?
- are QA people involved?
- most importantly: what really happens on push, what is pushed code?
- onboarding
But do you need a workflow at all?

6. Often the choice of the tool is not yours. This does not mean you can't bore
everyone about switching to git!
man:
"git - the stupid content tracker"
"No manual entry for hg"
why is git a better tool for your flows and
is it?

7. git is unfriendly but ultimately simple tool that will empower you the better you
get
hg is friendly but ultimately complex tool what will get in your way the better
you get
Linus Torvalds did not write git, stop associating it with his mean spirit.
How much does speed mean to you?
it’s git in case you’re wondering

8. What is a change-log like history
Either. But don't mix merge and rebase.
Release Masters care about changelog-like history.
Ninja developers care about changelog-like history.
In practice this kind of history is difficult to have but this shouldn't
stop us from trying.
Merge or rebase?

9. workflow ninja, merger(rebaser), blocker, changelog crafter, QA person,
whatever
roles are OK - be open about how to take on a more responsible role and stress
responsibility.
workflow roles

10. My current project - three people, one reviewer, easy-to-spot mistakes, slow
dynamic, one development branch periodically released
Past project 1 - lots of developers, various unknown levels of git mastery, one
development branch, code-freeze, turns into many libraries, no QA people
involved
Past project 2 - few developers, many "layers" of people - web devs, QA people,
external devs. nice hooks,
Some messy project - no workflow defined or enforced, branches like
production, production2 and staging2
Some use cases

11. Do you feel you need a better defined workflow?
What pitfalls have you fallen in?
What are your experiences?