1. clone the master repository twice
   1. main
      
   2. sync
      
2. main: pull changes from the master repo
   
3. main: commit your your changesets to default tip or branch (5.0 | 4.3)
   
4. sync: pull changes from the main repo - get the new commits you want to push
   
5. sync: pull changes from the master repo - checks for new commits in the repo
   
6. sync: rebase your changesets to repohead if necessary
   
7. sync: push your new local commits to master repo head or branch

Do not force a commit (will cause a branch). Avoid the risk of causing multiple heads.

% hg push
pushing to https://bitbucket.org/wackowiki/wackowiki-dev
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)	

2.1. Step-by-Step

Use two clones. Do all your work in clone "main", and all your merging and pushing from clone "sync". Let's say the main repository is "master", and your two clones are "main" and "sync":

To get set up, either clone the master repository twice, or, you can clone your main locally, but be sure to update the "parent" reference in your sync clone such that it points to the master instead of your working clone (I do that by copying main/.hg/hgrc to sync/.hg/hgrc.)

Here's the workflow:

1. As before, work in main. Edit files at will, and check in logical changesets as needed.
2. When you want to push a changeset, go to your sync clone, and pull your new changesets from your working clone:

 % cd ../sync
% hg pull ../main && hg update	

3. Now pull in the new changes from the master, and merge these:

 % hg fetch	

4. If something went wrong with the merge - no problem. You can just go and nuke the entire sync clone and try again! Your modified files, and your new changesets, are still sitting completely unaffected in the main clone. Just clone sync again and try more carefully :)

5. Now you can push your merged changesets to the master repository:

 % hg push	

6. ...and now you can pull these changes back into your main repository:

 % hg pull ../sync && hg update	

This process may seem tricky, but it's trivial once you try it:

Finally, I want to call attention to item #4. Doing it this way means that it's trivial to try again if something wrong happens during the merge. I've had a couple of merges where I've really mucked things up. Unfortunately, this was in my tree that contained the changesets that I cared about. In the end I had to go and manually copy out the files I wanted to check in and try again. With the above approach, if something goes wrong, just nuke the sync clone and try again.

This is the reason I'm suggesting this approach to anyone using Mercurial, not just people who want to work with edited files. Especially when you're new to distributed version control systems or Mercurial, it's great to be able to go back if you make a mistake. Just make sure you know what you're doing before you submit that final hg push command to push everything back to the master repository!

Simplify your history, in the most intuitive and clutter-free way to combine commits from multiple developers in a shared branch.

3.1. Rebase

Workflow using the Rebase Extension.

Suppose you have a history like this: hg log -G

@  changeset:   2:81b92083cb1d
|  tag:         tip
|  summary:     my new feature: edit file a
|
o  changeset:   1:8bdc4508ac7b
|  summary:     my new feature: add file b
|
o  changeset:   0:d554afd54164
   summary:     initial	

This means, revision 0 is the base on which you started to work on your feature. Now you want to have revisions 1-2 on a named branch, let's say my-feature. Update to revision 0 and create that branch:

 
$ hg up 0
$ hg branch my-feature
$ hg ci -m "start new branch my-feature"	

The history now looks like this:

 
@  changeset:   3:b5939750b911
|  branch:      my-feature
|  tag:         tip
|  parent:      0:d554afd54164
|  summary:     start new branch my-feature
|
| o  changeset:   2:81b92083cb1d
| |  summary:     my new feature: edit file a
| |
| o  changeset:   1:8bdc4508ac7b
|/   summary:     my new feature: add file b
|
o  changeset:   0:d554afd54164
   summary:     initial	

Use the rebase command to move revisions 1-2 onto revision 3:

$ hg rebase -s 1 -d 3	

This results in the following graph:

 
@  changeset:   3:88a90f9bbde7
|  branch:      my-feature
|  tag:         tip
|  summary:     my new feature: edit file a
|
o  changeset:   2:38f5adf2cf4b
|  branch:      my-feature
|  summary:     my new feature: add file b
|
o  changeset:   1:b5939750b911
|  branch:      my-feature
|  summary:     start new branch my-feature
|
o  changeset:   0:d554afd54164
   summary:     initial	

That's it .. moving around already pushed changesets generally is a bad idea, unless you work in a small team where you are able to communicate and enforce your history manipulation.

3.2. Mercurial Queues

Workflow using the MqExtension. Let's say the changesets to move are revisions 1-3:

hg qimport -r 1:3    # convert revisions to patches
hg qpop -a           # remove all them from history
hg branch new        # start a new branch
hg qpush -a          # push them all back into history
hg qfin -a           # finalize the patches	

Mq can only convert consecutive changesets from a head. It turns normally immutable changesets into mutable patches that can be edited.
Don't edit changesets that have been pushed. Mq changes the hashes so they will be effectively new changesets. Only edit history that hasn't been pushed.

Suppose you have a history like this: hg log -G

#default branch
@  changeset:   3:cb292fcdbde1
|
o  changeset:   2:e746dceba503
|
o  changeset:   1:2d50c7ab6b8f
|
o  changeset:   0:c22be856358b	

and we want

  @  changeset:   3:0e85ae268e35
  |  branch:      feature/my_feature
  |
  o  changeset:   2:1450cb9ec349
  |  branch:      feature/my_feature
  |
  o  changeset:   1:7b9836f25f28
  |  branch:      feature/my_feature
  |
 /
|
o  changeset:   0:c22be856358b	

hg export -o feature.diff 1 2 3
hg update 0
hg branch feature/my_feature
hg import feature.diff	

Here is the state of your local repository

@  changeset:   6:0e85ae268e35
|  branch:      feature/my_feature
|
o  changeset:   5:1450cb9ec349
|  branch:      feature/my_feature
|
o  changeset:   4:7b9836f25f28
|  branch:      feature/my_feature
|
| o  changeset:   3:cb292fcdbde1
| |
| o  changeset:   2:e746dceba503
| |
| o  changeset:   1:2d50c7ab6b8f
|/
|
o  changeset:   0:c22be856358b	

Now you need to delete the revisions 1 2 and 3 from your default branch. You can do this with strip command from mq's extension. hg strip removes the changeset and all its descendants from the repository.

And now strip this repository on revision 1.

 hg strip 1	

now we got

@  changeset:   3:0e85ae268e35
|  branch:      feature/my_feature
|
o  changeset:   2:1450cb9ec349
|  branch:      feature/my_feature
|
o  changeset:   1:7b9836f25f28
|  branch:      feature/my_feature
|
o  changeset:   0:c22be856358b	

note: changesets are different but revisions are the same

3.3. Conclusion

When multiple developers work on a shared branch, pull & rebase your outgoing commits to keep history cleaner

https://stackoverflow.com/ques[...]nges-to-a-new-branch