Can't do proper git pull request

Question

I'm new to GitHub and therefore I messed a lot with it, so I need some step-by-step help. Sorry for being annoying :/ Also, before I say anything, I'd have to clarify that I used only GitHub, because I encountered some problems with Git Bash.

Antefact: I forked a repo, did some commits and sent a pull request. However, it had some conflicts. I contacted the programmer, and he said he'll merge my pull request later.

Now, I had to do some other commits, but meanwhile the original repo had been updated with 30+ commits. I didn't know how to do a new updated fork, so i created a new repo, manually uploaded there his updated repo, and did my commits. Obviously, now I can't do a pull request since git doesn't recognize what to compare.

Now, what I'm asking for, is just to be able to do that pull request. I'm also prepared to redo my commits on a new fork/branch, if someone can help me create it. If needed, I can also use Git Bash of course, but I'll need really some step-by-step help because I read something on the internet but every command I launched didn't fit what I read. Obviously I can't delete my first repo because the merge hasn't been done yet.

Answer 1

It seems your best option for now, although it's a very bad practice overall, would be moving the files from your new repository to the forked one and issue the pull request again (overwriting all files with the updated ones).

Before you do that, you should consider to pull changes or make sure your local repository is up to date with the original forked repository.

These might be useful for the future https://services.github.com/kit/downloads/github-git-cheat-sheet.pdf https://www.git-tower.com/learn/cheat-sheets/git

Answer 2

An answer has already been posted, but to stop such thing from haplening again:

GitHub is just a Git-Host of many and works like any other (GitLab, Gogs, ...).

That out of the way I recommend learning Git (and not "learning GitHub"). Git is a really nice SCM but it's not trivial. I personally always like to recommend "Think Like A Git", imho the best introduction.

If you clone a repo you actually do many things:

• Initialize a new local git repo
• Add the remote (URL) you clone from
• Fetch it's data (the commits)
• Checkout a branch (often called master, but that's just convention) wtih the same commit-history as the corresponding branch on the remote

If you fork a repo, everything that GitHub does is to copy the forked remote to a new namespace under your account. You can now clone your repo, which you have write-permission to.

Now you want to pull-request. A pull request on GitHub (it's a GitHub-specific feature, albeit other servers often implement similar functions) work the way that you specify a source remote/branch-combination and a target remot/branch.

Because of that it's considered good style to create a new branch in your repo which branches from the actual branch you want to merge into later on and dedicate it to commits only for the pull-request. I often use a naming scheme like "PRQ_myfeature".

With this method you can still let your master branch "track" the master branch of the original remote. In order to do that use "$ git remote add some_fancy_name URL". You can now fetch and pull the original master into yours to keep track of the changes.

This also enables you to regularly rebase your pull-request branch and check for conflicts.

This means the author can just merge your pull-request without problems which makes it tremndously more likely that they'll do so ;)