6

I am not the best Git user, and am having an issue whenever I create a PR. Basically, when I make a PR, I am shown a large list of all my previous commits including the one that I just committed (the one I want merged to Master branch). The flow that I do is the following:

First I fork a copy of our Master branch, and

git clone [local copy]

Then I create a remote

git remote add upstream [main repo url]

Then every time I have made changes I want to add to my PR:

git add [file1] [file2 ] ...ect

Then commit:

git commit -m 'blah blah blah'

And finally push to origin:

git push origin master

After this, I create a PR on Github, where it shows all the previous commits. Is there a way to not list all of these and only show my latest commit? It shows commits that were merged to the upstream long back and are in sync with it. It would be nice for the merger to not have to select the specific commits and just the ones listed.

Thanks!

Angelo
  • 173
  • 1
  • 1
  • 4
  • You can keep all your changes in stage, and commit everything once you are ready to PR – InGeek Jan 27 '17 at 01:24
  • That's how a PR behaves. You want individual commits? Then create individual PRs for each commit. PR represent all changes in your forked repo's `main` brnach that is not reflected in the main repo's `main` branch – astrochun Mar 24 '21 at 15:35

2 Answers2

1

Your workflow does not seem right. There are two options how you can contribute:

  1. You have write permission in the upstream repository. Then You should simply clone the upstream repository, checkout a new branch git checkout -b fix/my-fix and commit your changes there. Once you are done, you push your new branch to upstream git push origin fix/my-fix and open a PR inside that repo.

  2. You don't have write permissions, i.e. you can't push any branches to the upstream repo. First you have to create a private fork of the repository, then clone your fork to your computer. Also now you should create a new branch for your fix or feature addition. Once you have that, you push the branch to your private repo. This part is a bit confusing, but github will make it work. You can then open a PR in the original upstream repo from within your forked repo. For that, navigate to your github profile and your repository and start a PR with your new branch. You should be able to chose the upstream master as the merge target for your new branch.

If you still see all the old commits when you open a new PR, then your branches have diverged, someone force pushed changes to master or something like that. You can check the common ancestor of two branches branch_1 and branch_2 with git merge-base branch_1 branch_2. Then you can use interactive rebase git rebase-i to put your branch on top of another one and drop all unnecessary commits.

Potaito
  • 1,181
  • 2
  • 10
  • 32
-3

Assuming PR means Pull Request, that is exactly what you should see - all commits since the repository was last cloned. Generally, it is a good idea to keep those commits as they will tell all what and how things have changed.

However, if this is a case of "over committing" as a result of committing whenever something changed rather than when a task or problem has been solved, then you can certainly squash/rebase your commits into one. See the following for details

Community
  • 1
  • 1
Frelling
  • 3,287
  • 24
  • 27
  • 3
    How can that be desirable? Shouldn't it just show the differences between the base and what you want to pull in? The earlier commits that have already been merged in shouldn't show up. – Gusutafu Mar 14 '18 at 14:09