{{toc numerate=1}}
1. The **Fork + Pull Model** lets anyone fork an existing repository and push changes to their personal fork without requiring access be granted to the source repository. The changes must then be pulled into the source repository by the project maintainer. This model reduces the amount of friction for new contributors and is popular with open source projects because it allows people to work independently without upfront coordination.
1. The **Shared Repository Model** is more prevalent with small teams and organizations collaborating on private projects. Everyone is granted push access to a single shared repository and topic branches are used to isolate changes.
Pull requests are especially useful in the Fork + Pull Model because they provide a way to notify project maintainers about changes in your fork. However, they’re also useful in the Shared Repository Model where they’re used to initiate code review and general discussion about a set of changes before being merged into a mainline branch.
Comparison of Subversion and Git workflow
* ((file:subversionarrows1.png Subversion workflow))
* ((file:/git_workflow.png Git workflow))
++source: https://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/++
===Fork + Pull Model===
1. **Create a fork of the repository.** Go to the repository that you want to fork. This gives you a copy of the code from the point where you fork it.
1. **Clone your new fork.** Now you may clone your new repository, to create a local copy.
1. **Work on the files locally.** Edit the files, add new files, and so on. It is your repository.
1. **Commit changesets to your local repository** as usual.
1. **Push your changes up to your fork.** Push your changes to Bitbucket in the usual way. This will update your fork of the repository.
1. **Send a pull request to the owner of the original repository.** Once you are satisfied with your changes, you can ask the owners of the original repository to pull in your changes and merge them into the main repository. Send a 'pull request'. The Issue tracker will send a notification to the owner, making it easy for you to communicate with them about your changes from this point onwards.
====Step-by-Step Example – First the Fork===
1. Create a fork of the repository
2. Clone your new repository (the fork), so that you can start working on it locally.
1. Work on your files locally, as usual.
1. Push your changes to your repository (the fork)
====Step-by-Step Example – Now the Pull Request===
===Shared Repository Model===
{{include page="!/SharedRepositoryModel"}}
===Keep the history clean===
{{include page="!/KeepTheHistoryClean"}}
===Links===
1. ((http://www.igvita.com/2011/12/19/dont-push-your-pull-requests/ Don’t “Push” Your Pull Requests))
1. https://www.mercurial-scm.org/guide
1. https://www.mercurial-scm.org/wiki/WorkingPractices
2. ((http://tornorbye.blogspot.com/2008/10/mercurial-tip-checking-in-regularly.html Work in main, push and merge in sync, and pull back into main.))
3. ((http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ A Guide to Branching in Mercurial))
4. https://www.mercurial-scm.org/wiki/NamedBranches
* ##hg push -r branchname-to-push## Only push branches you want to push. If you want a disposable branch, just don't push it and then strip it once you decide you don't want it anymore.