Question

Let me see if I got this right, I’m new to Git.

1. Assume I’ve created a fork of a project on GitHub and made some changes. If I were to commit, push and register a pull request of these changes its considered good practice to create a new named branch with a name specific for whatever I did.

2. Because If I just used master and then pushed other (unrelated) changes to master on my fork they would automatically be appended to the pull request. At least that’s how I understand the following from using pull requests:

Pull requests can be sent from any branch or commit but it’s
recommended that a topic branch be used so that follow-up commits can
be pushed to update the pull request if necessary.

Assume that the pull request is accepted by the maintainer.

1. If my topic branch is merged, all I need to do to get back in sync is fetch from the maintainers repo.

2. But if the topic branch is rebased history has been rewritten and a fetch from the maintainer repo would yield me a “duplicate” of my topic branch (at least this is how it works in mercurial).

3. Regardless if my branch is merged or rebased the branch (or rather the name) is deleted. Making the maintainers repo contain a single master branch.

Answer 1

In case you’ve posted stuff to your master branch that isn’t in upstream/master (upstream being the remote handle to the official repo) I’d recommend rolling back master a couple of commits and then merging upstream/master back in:

>> git checkout master         # make sure we're on master
>> git branch oldmaster        # create a new branch, just to be safe
>> git reset --hard HEAD~100   # roll back 100 commits
>> git fetch upstream          # fetch newest changes from upstream
>> git merge upstream/master   # merge the main master branch into your local one

You should end up with your messy master branch in oldmaster and the official one in master.