ML was my first foray into the world of distributed version control. I have learned a lot from reading and making mistakes, and I thought I'd share what I've learned and my general workflow here in the hopes that it will be useful to other DVCS newbies.
If you're not already an expert on mercurial, see: http://hginit.com/
I assume you already know how to do basic stuff like clone/add/commit/branch/merge etc. I also recommend finding a nice GUI that you like (I use SourceTree, its nice, but Mac/Windows only and IMO the mac version is superior to the windows)#1: Branches over Forks
In DVCS there's not really much difference between a branch and a fork (clone). You can use both to work on something outside of the main 'trunk' and then merge it back later. But there are some very good reasons to use branches rather than multiple forks (like I see a lot of ppl do, and like I did starting out). The main reason is that it is much easier and faster to switch your working copy between branches of the same repo, than it is to change repos entirely. This comes in very handy (more on that later). You don't have to submit a pull request (PR) from your 'unified' branch to the main repo's 'unified' branch, you can select any of your own branches to submit a PR from, which leads into the next point...#2: Don't commit to 'unified' in your fork
If you keep unified (the main branch) 'pure and undefiled' then you know every time you click the 'sync now' button in your bitbucket fork (and then pull to your local), 'unified' will contain exactly the current state of the main repo. If you want to do a 'quick-fix' patch to the current main, you can just create a new branch off of 'unified' at the current point in time, and submit that branch as a PR without worring about it containing any of your other, unrelated WIP or a pending PR.
Another use of this is that you can easily switch to unified and build if you want test that an issue is being caused by ML main or your own code. Switch to 'unified' and build, then run some tests, switch back to your own branch, build and test. Now you know the source of your issue. If you have uncommited local changes when attempting to switch branches, you can easily 'shelf' them and restore them later.
This also allows you to keep using the same fork and keep it up to date, even if you have a PR pending for a while (which happened to me frequently).#3: Keep your personal tweaks in their own branch
We all have our own personal tweaks for ML (disable the warning screen, flexinfo customizations, etc) that would never get merged. To avoid them finding their way into your PRs, keep them in a separate branch. This makes it easy for you to still keep them under version control and easily merge them with updates from your other feature branches (that are intended to be PRs) and changes from the main repo.#4: Use a 'working' branch
So now you've got a bunch of branches for each different feature you're working on and for your tweaks. You say: now I can't use all of them together for my own working version of ML that I actually use day to day out in the field. Wrong! This is where the 'working' branch comes in. The purpose of this branch is simply to create your 'working' version of ML, with all your changes, pending PR, and tweaks all combined. All you do is simply create this branch and merge all of your other branches to it. Don't ever work on this branch or commit (other than merge commits) stuff to it. It's simply there to be merged onto, like a 'branch aggregator.' (You can even pull other dev's tweaks that you want to use into your working, like 'unsafe' stuff from TL)
Make your changes in other branches and then merge them into this branch. This lets you keep you changes separate (so you can easily PR them separately). When you are testing and working on certain things, you do it in those particular branches. This helps you know the source of bugs. If you're working on two different features at the same time and you have a bug, you might not know which feature is the source, unless you keep them separated like this, then you'll know instantly. Finally, when you're done developing/testing and ready to have Your Version Of ML™
to work with in the field, just merge everything to working and build.#5: Close unused branches
This wasn't exactly intuitive to figure out how to do in bitbucket so I'm simply sharing how you do it, so that you can keep your 'tree pruned' from branches you're no longer using:
Click on 'branches' in bitbucket.
For the branch you want to close hover your mouse near the right edge of the list, you'll see three dots.
Click and you get a pull down with an option to close the branch.
If you have any additional tips, please share them. I'll update this post with others' tips or new things as I learn them.