11

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:

  • checkout master that track original repo
  • brahnch from it
  • cherry-pick from feature and push it to GitHub
  • submit a PR

When 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.

Vladimir
  • 1,363
  • 2
  • 14
  • 28
  • Not really an answer, but that's the way I've been using pull requests as well. If your own repo is ahead of the _upstream_, you'll have to branch of the _upstream_'s master branch to avoid pulling in all of your changes. I also use cherry-picking for moving changes between my fork and the branch for the Pull Request. – nwinkler Mar 05 '15 at 14:45

3 Answers3

7

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.

Ryen Nelsen
  • 367
  • 1
  • 9
  • Ryen, thanks for the answer. Perhaps I was not clear enough - master/develop separation is not really an issue - usually I follow gitflow paradigm. What I'm interested in - how to send pull-request for only **feature-X**, given that my **develop** is way ahead of the original repository? I use cherry-picking, but is it the best way? – Vladimir Mar 07 '15 at 18:53
2

I agree with Ryen that it depends on what project.

At my work we've come up with a pretty nice system that we all agreed upon.

  1. Start on latest master.
  2. Work on your development or feature work
  3. git add -p (for your changes) or git add <filename> for new additions
  4. git checkout -b new-branch-name
  5. git commit -m "whatever you feel should be said"
  6. git pull -r origin master
  7. git push origin new-branch-name
  8. open a pr and wait for 2 approvals
  9. merge into master
  10. delete new-branch-name

After that we just go back to master and repeat. If someone requests changes we stash whatever we're working on and checkout new-branch-name, make the requested changes, do a git pull -r origin master again, then git push -f origin new-branch-name, then checkout master and git stash pop. Sometimes you do get in a spot where you need the changes you made, in that case we just continue working on that new-branch-name and don't delete it locally, only on github or whatever you use.

I know I kind of broke it down barney style, but I didn't want to miss something. Feel free to use it. It also works so well for us because we talk and collaborate a lot. As far as forked repos and prs, just open a pr whenever you're happy with what you have been working on. I don't agree wholeheartedly with the whole, branch off master to a dev branch, then branch off of that. Master should be prod ready at all times and then if you're sticking to those prs you don't need to worry. Also if you're scared of a big pr feel free to require multiple people to review it, and it doesn't have to just be two. We only have 6 people so 2 works for us. Hope that helps.

MonkeyTonk
  • 55
  • 10
Richi Jeffery
  • 183
  • 7
0

Given the comment posted by OP on Ryen Nelsen's answer:

... master/develop separation is not really an issue - usually I follow gitflow paradigm. What I'm interested in - how to send pull-request for only feature-X, given that my develop is way ahead of the original repository? I use cherry-picking, but is it the best way?

I will ask - what do you mean that your develop branch is way ahead of the original repository (what I'll call the master branch from now on)? What are all the other things in your develop branch?

It sounds like you are completing significant development in develop that is not going into master in the short-term. In this situation, create a separate feature branch for each Pull Request/issue/enhancement that you are working on that will be submitted to master.

If you are careful, you can minimize the differences between your various feature branches, including the interdependencies discussed in the quote. For example, say you are maintaining develop and trying to submit pull requests to master for fea1 and fea2.

  • Setup the 2 feature branches off of master and Cherry-pick or Rebase out of develop to fea1 and fea2 until they have the base you need from existing develop changes to make your fixes.
  • If there are interdependencies, that just means you will cherry-pick some of the same commits to each feature branch, or will end up developing new code that will be merged or rebased between the two feature branches.
  • Develop the new fixes for fea1 and fea2, and merge (or rebase/squash) to develop as you find appropriate. Merging in this context, where you are the only one developing in this repo is simple - you'll only be working on one of develop, fea1, or fea2 at a time, so merging is truly going to be handling conflicts that you have to solve anyway...

Once prepared for the pull requests, you can leave fea1 and fea2 sitting in their own separate branches, and continue working on develop separately. Meanwhile, as the Pull Requests get feedback you can always checkout fea1 or fea2 and update them, perhaps requiring a merge from fea1 to fea2 or vice versa, and likely also needing to merge the new commit(s) back down to develop so it stays up-to-date.

Once the PRs are accepted, you can clean-up anything you need to on the corresponding private feature branch in your repo, and make sure any final merges to the other branch and develop are complete.

You could then delete the feature branch, but personally, I'd tag the last commit so I could come back to it in the future if needed, and then delete the branch reference. That way you can come back to a commit that is likely a lot closer to master than develop is, though depending how much time has passed, maybe not - at least you'll have a choice. This could happen, for example, if a defect in your PR gets into master, and a new issue is opened that you can squash quickly, but would take someone else a lot longer.

LightCC
  • 9,804
  • 5
  • 52
  • 92