Menu
I've read this and this discussions but still have troubles with understanding the best way of collaborating on GitHub.
Suppose I've forked a repo and develop it independently (the original repo has not been active for a while). So I do have my own develop branch, where I do all changes: branching from feature it, developing there and then merging back to develop. From time to time I want to submit a PR to original repo. But I can't do PR from feature, as it will include all history of develop. So that's what I do:
master that track original repofeature and push it to GitHubWhen those PR's are merged to master of original repo, I pull from it and then merge master to develop.
It works rather fine, but it results in multiplying identical commits in my own repo, so I'm not sure if cherry-picking is the best way here?
Branching from master would be perhaps better, but often there's a situation when I've done feature-2 that depend on feature-1; and feature-1 is still waiting as PR to be merged, but not in master yet.
I would appreciate any suggestions and examples.
449
Be explicit about what feedback you want, if any: a quick pair of :eyes: on the code, discussion on the technical approach, critique on design, a review of copy. Be explicit about when you want feedback, if the Pull Request is work in progress, say so.
To me, two times a day is a good interval for when to review. I like to check for pull requests in the morning and after lunch. At those times you naturally have a break from all the context you've built up in your mind.
Have one commit per logical change and one major feature per pull request. When you submit a pull request, all the commits associated with that pull request should be related to the same major feature.
How can we determine the perfect pull request size? A study of a Cisco Systems programming team revealed that a review of 200-400 LOC over 60 to 90 minutes should yield 70-90% defect discovery. With this number in mind, a good pull request should not have more than 250 lines of code changed.
In theory it always depends on the project you are working on, and the head of the project.
Generally speaking you only commit to master when it is a release build, or something that can at least compile without errors. But some project just throw everything into master.
Truly, in my own projects, and opinion, your pull requests should be placed into the main projects develop branch, then when the time comes, everything from develop gets merged into master.
Your workflow would basically stay the same. Branch from develop to create a new feature-X, commit to feature-X, and then you would submit a pull request on feature-X. Once merged into develop you would pull that down, and continue working; or just merge it on your personal fork and continue working, git should understand. Once the project lead feels the project is in it's next version, he/she would merge develop into master.
Check out this 5 minute read: Understanding the GitHub Flow.
153
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
