Git pull request flow
29 June ’12
Everybody says that the ultimate feature of Github is pull request because it enables people to develop asynchronously and even to do it before showing-up. Interested developer doesn't need to wait for some rights to push and he can directly start to the development on his personal copy.
I am also preparing my first pull request and the idea itself even gets me excited.
To my initial exposure to fork, a certain git flow is required. So far the best way seems keeping main copy in the master and not to touch it for fork related edits. It should only be used to pull main stream commits. If our valuable contribution is going on in the another branch, expected pain is significantly low. Moreover, some notes for this separate branch:
- It is better that the name of the branch is descriptive for the goal of the fork.
- Pushing changes regularly to the server is also better because the developer of the main repository may follow what we are doing and even give some advice which can prevent some valuable hours to be wasted. Like we get excited when we fork a repo to contribute, the owner also gets excited because he thinks that he is doing great work, people are aware of him and intrinsically starts to wonder how forker will help but By the way, it should be noted that no development is done in 2 of 3 forks.
- Don't merge master with the other branch before it is accepted. What if it isn't accepted? Waiting is easier than doing git hack.