-1

When I merge a pull request on GitHub and then run git pull -a on the local repository I found another commit: Merge branches 'blabla' and 'main' of github.com:repository, and in the log, there is written: Merge made by the 'ort' strategy. Then I'm forced to push this commit.

Steps to reproduce:

  1. Create a repository and commit
  2. Create a branch and make some changes, then push
  3. On the GitHub portal click "Create a pull request" and merge
  4. On your local repository run git pull -a on the main branch
  5. The new commit appears.
  6. now you must run git push

The problem is that on the GitHub repository, there are Actions workflows that run when a commit is done on the main branch.

What is the correct workflow to do a pull request and reconcile the local repo without creating another commit?

Edit: I'm the only person who interacts with the repo

Guildenstern
  • 2,179
  • 1
  • 17
  • 39
Max
  • 6,821
  • 3
  • 43
  • 59
  • You shouldn't get any extra merge commits if all those steps were done by you. You only get them when someone else does something remotely (in addition to you). – Guildenstern Aug 09 '23 at 11:40
  • Try `git pull --ff-only`. – Guildenstern Aug 09 '23 at 11:40
  • The question might be clear enough in case this might be illuminating (at least a bit): [Beginner question on "Pull is mostly evil"](https://lore.kernel.org/git/0C723FEB5B4E5642B25B451BA57E2730751C2642@S1P5DAG3C.EXCHPROD.USA.NET/) – Guildenstern Aug 09 '23 at 12:01
  • 1
    Shouldn't the first action item (before the downvoters explain) be that you give feedback to the answer you received? Because that can be a form of clarification. – Guildenstern Aug 09 '23 at 12:35

2 Answers2

2

There's a couple of details about git that lead to this behavior:

  1. Your local main branch and origin/main are completely independent branches.

  2. git fetch origin downloads any changes from the origin repo (e.g. new commits or new branches), but it does not merge them with your local branch (i.e. your local main branch remains untouched). To actually see the changes on your file system, you need to check them out, e.g. using git reset --hard origin/main.

  3. git pull origin main performs a git fetch followed by a git merge. Usually, git will perform a so-called fast-forward merge where it will simply advance your local main to origin/main, but if that's not possible for some reason, it will create a full merge commit instead.

For this reason, I am always using the following workflow and I'd recommend you do the same:

  • Never use git pull as it might have unintended side effects.
  • Instead, always use git fetch origin followed by git reset --hard origin/main (replace the branch name with whatever you are currently working on).

Alternatively, you can use a UI like GitKraken, Git Extensions or SmartGit which will visualize the current situation for you.

If you want to dig deeper, I highly suggest this YouTube video that explained it to me.

vatbub
  • 2,713
  • 18
  • 41
0

There are several mistakes here:

  • If you are the only person using this repo, you should not be using pull requests. Pull requests are not a Git feature; they are a GitHub feature, and are present only to facilitate collaboration. You're not collaborating so pull requests are pointless and are just complicating your life unnecessarily.

  • If you do decide to use pull requests to merge into main, then you should not have a local main. You don't need it for anything, because you are never going to merge into it. If you need to start a new branch at the end of main, or just investigate the state of main, do a git fetch and look at origin/main, the remote-tracking branch. I have explained elsewhere how I work without a local main.

  • Either of those suggestions would have obviated the need for this question. But if you do have a local main, you should still be following the rule: don't ever say git pull. It is nondeterministic in its behavior (at least from a user point of view; it has reasons for how it behaves, but it's difficult to find out what they are) and it doesn't do anything that you can't do much more cleanly by saying git fetch and then proceeding to merge or rebase or whatever.

matt
  • 515,959
  • 87
  • 875
  • 1,141
  • 1
    Well, as a matter of fact, PRs can still be useful, even when you work on your own. In my case, even though I am the only person working on the project, I am still switching between feature branches and PRs are a great way to keep CI status in one place and allow me to review my own code before I merge it – vatbub Aug 09 '23 at 17:22