My pull request has been merged, what to do next?

Question

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 b

Answer 1

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.

Answer 2

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.