119

I recently participated in a project from GitHub. I did the following:

Forked the original repository, cloned it to my local machine, made a branch to fix existing bug, fixed bug being in that branch, pushed that branch to my repo, send a pull request to the author of the repository to merge my fix branch to its master branch.

It was my first time I commited on another's code so I don't know what to do. Now my pull request has been merged to original repo/project by the author.

What should I do next? Should I delete the branch? Should I merge the branch? Anything else?

Additional info:

The original project has a single branch.

I also have a upstream set to get latest updates form the original repo. (I did it like this):

git remote add upstream https://path/to/original/repo.git

And I get updates like this:

git fetch upstream
Santosh Kumar
  • 26,475
  • 20
  • 67
  • 118
  • 13
    Ghehe, you're not the only one struggling: [Youtube Video](http://www.youtube.com/watch?v=CDeG4S-mJts) `:)` – Anne Oct 07 '12 at 16:25

2 Answers2

75

What to do next is: going on contributing new features or fixing other bugs in their own dedicated branches (pushed only to your fork).

Meaning your fork stays, but the branches within your fork can come and go.

You can also remove the fork if you are not planning to contribute further, but it will remove the corresponding entry in 'Repositories you contribute to'.

It is easier to:

  • delete your fix branch (actually, it is now deleted for you) on your fork (and in your local cloned repo: see "Delete a Git branch both locally and remotely")
  • git pull upstream master (if master was the branch in which your fix has been integrated: the merge will be a fast-forward one): no rebase needed at this point.
  • recreate a fix branch on top of your updated local master (now with the latest from upstream master).

However, never forget one step before submitting any future pull request:

rebase first your current branch (fix) from upstream destination branch

(upstream being the original repo you have forked: see "What is the difference between origin and upstream in github")

Before submitting anything back to the original repo ("upstream"), you need to make sure your work is based on top of the latest from said original repo (or the pull-request won't result in a fast-forward merge once applied back on upstream repo).
See, for instance, "Workflow for managing pull requests on shared repos in github".

In other words, upstream can evolve (have new commits pushed on it) while you are busy fixing stuff. You need to replay your fixes on top of that latest work from upstream to make sure your commits are still compatible with the latest of upstream.

The OP Santosh Kumar asks in the comments:

I have pulled and merged from upstream to master, now what?

If you haven't made any new fixes since your recent pull request, see above (delete and recreate an new branch fix on top of your updated master).

If you have done any more work since your pull request, I wouldn't merge from upstream if I want to make a new pull request: I would pull and rebase:

git pull --rebase upstream master

That way, all my new local work is replayed on top of the most recent upstream master commits (fetched in my local repo), supposing that master is the target branch that will integrate my future pull request.

Then I can push my local work to 'origin', which is my fork on GitHub of upstream.
And from my fork on GitHub, I can safely make a pull request, knowing that it will only add new commits to upstream without needing any merge resolution: merging those new commits in upstream repo will mean a simple fast-forward merge.

A git pull --rebase without specifying the branch on top of which you want to rebase your (currently checked out) fix branch wouldn't work:

That (git pull --rebase) says: 

You asked to pull from the remote '`upstream`', but did not specify a branch.

Should I append master at last? And what will this do?, will it delete my fix branch?

Yes, you can specify the branch which will be the target of the pull request, for instance 'master'.
That will not delete your fix branch, but will replay it on top of upstream master fetched in your repo.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Can you explain the **rebase from upstream** part? – Santosh Kumar Oct 08 '12 at 15:49
  • @SantoshKumar you need to rebase your local commits on top of the original repo (here referenced as upstream) before pushing to your fork and making your pull request: see http://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-in-github/9257901#9257901 – VonC Oct 08 '12 at 15:53
  • Ya, I know I'm asking a **basic** question. I have pulled and merged from upstream to master, now what? – Santosh Kumar Oct 09 '12 at 01:52
  • @SantoshKumar it is a good question. I have edited the answer to address it. Look for "The OP Santosh Kumar asks in the comments:..." – VonC Oct 09 '12 at 05:42
  • That says: `You asked to pull from the remote 'upstream', but did not specify a branch.` Should I append `master` at last? And what will this do?, will it delete my **fix** branch? – Santosh Kumar Oct 10 '12 at 03:08
  • @Santosh yes, you can specify the branch which will be the target of the pull request. That will not delete your fix branch, but will replay it on top of upstream master. – VonC Oct 10 '12 at 03:46
  • Is *fix* branch of any use? Should I merge/delete it? – Santosh Kumar Oct 10 '12 at 03:58
  • @Santosh as long as the pull request isn't done and accepted, it is a good practice to keep your evolutions in a separate branch ( here "fix"), that you can publish/push to your own fork – VonC Oct 10 '12 at 04:38
  • My pull request has been merged. And what did you exactly mean? Should I create a new branch *e.g. myprogress* and keep merging all my `fix1`, `fix2`, `fix3` to it after the fixes are pulled to original project? – Santosh Kumar Oct 10 '12 at 05:43
  • @SantoshKumar Excellent: if your pull request has been merged, then you need to delete your fix branch (since all of its commits have been integrated in upstream), and create a new one (you can still call it fix, you don't need to increment a counter), on which you would resume new fixes on top of the most recent upstream commits (which now include your first pull request) – VonC Oct 10 '12 at 05:53
  • Which answer should I accept? You congrats me on my first contribution and I will choose yours. :D – Santosh Kumar Oct 10 '12 at 05:59
  • @SantoshKumar simple: choose the one that actually helped you ;) – VonC Oct 10 '12 at 06:00
  • I think both the answers are saying the same thing, *delete the fix branch*. And I think `git pull --rebase upstream master` and `git fetch upstream` does the same work :/ – Santosh Kumar Oct 10 '12 at 06:07
  • @SantoshKumar no, a `git fetch upstream` won't replay your work on top of upstream, which is my point. I am editing the answer to make that clearer. – VonC Oct 10 '12 at 06:09
  • Hey! I have deleted my local `fix` branch and pushed *(my master)* to remote. But I think fix branch is still at remote *(GitHub is showing)*. – Santosh Kumar Oct 10 '12 at 06:58
  • @SantoshKumar true, you might want to delete it on your fork as well: http://stackoverflow.com/questions/2003505/how-do-i-delete-a-git-branch-both-locally-and-in-github – VonC Oct 10 '12 at 07:03
  • This is all quite confusing, since the answers are not clearly distinguishing between the "fork" and the "branch", and are answering many other related questions at once. Is the clear answer to OP's question this? "Yes you can delete both the branch and the fork you have created. You can keep both alive if you want to make further contributions if you wanted to, but you have to pull from upstream to keep it current". If so, I suggest that this is added at the beginning of the answer for clarity. Cheers! – Gazihan Alankus Jan 22 '15 at 10:52
  • Also it seems removing your fork will hide the project from the 'Repositories you contribute to' list as per http://stackoverflow.com/a/28005723/679553, so maybe that should also be added to the beginning of the answer as it may be an important factor for the decision that OP will make. – Gazihan Alankus Jan 22 '15 at 10:58
  • @GaziAlankus no confusion there: the fork stays, the branch goes. I have edited the answer. – VonC Jan 22 '15 at 11:42
  • Thanks for including all the links for the intermediate steps instead of just saying do X or do Y. – typesanitizer Jul 29 '16 at 16:00
22

First, congratulations for your first contribution to a project on Github.

The usual Github workflow is to create a new branch for every problem you solve. That way the maintainer of the mainline repository can decide which one of your solutions to merge and which one to reject. After a branch got merged upstream, the branch won't be needed anymore and can usually be deleted.

Philipp
  • 67,764
  • 9
  • 118
  • 153