CODEWITHSUNDEEP
githubfork
Arne Claassen
Arne Claassen

Reputation: 14414

Git workflow for development on fork

I'm trying to figure out whether I should do my development on my clone of an upstream branch or create a local branch of it first, i.e.

  1. fork upstream
  2. work on my master
  3. issue pull-request against my master ... time passes ...
  4. merge upstream/master into my master
  5. back to 2.

or

  1. fork upstream
  2. branch my master into dev
  3. work on dev
  4. issue pull-request against dev ... time passes ...
  5. merge upstream/master into my master
  6. rebranch master or merge master into dev
  7. back to 2

The reason i consider the second workflow is for scenarios where my pull request isn't accepted or only partially accepted and once i merge upstream i want to make sure that my local is identical to upstream so i don't base future work on a divergent mutation of upstream. Or is there a command when i pull from upstream to master to make my local master identical to it (i.e. discard all local changes?)

Upvotes: 2

Views: 1416

Answers (2)

rubenvb
rubenvb

Reputation: 76795

There's also the very important git rebase that pulls/merges any external changes to the branch you rebase to. That's the way I committed changes to Qt in the past (which is hosted on gitorious which has the great merge request feature). Steps 1 and 2 will probably just be number two for you.

  1. create own clone of "master" on a seperate project
  2. work on the branch currently developed or create a new work branch.
  3. before making the pull request, do a git rebase origin/masteror something similar to make sure your commit applies cleanly to the current master. This has the nice side effect that your changes appear "on top of the stack", ie after all other commits.

Hope this helps you in what you're trying to do.

Upvotes: 0

mipadi
mipadi

Reputation: 411380

When dealing with an upstream repo, I usually do what I think your second workflow suggests. To wit:

  1. I create a branch from upstream's master. If I'm working on a specific feature or bug, I'll name the branch to reflect that; otherwise, I'll call it dev or whatnot.
  2. Work on dev, rebasing from upstream's master as necessary.
  3. Push dev (or whatever I called the branch) and issue my pull request.
  4. Continue pulling upstream's changes down into my master branch.

I.e., I don't do any work on master. This creates a simple, clean branch/pull request for the upstream maintainer.

Upvotes: 4

Related Questions