2

I have a class of students in which we all work in a repository and constantly check in small status updates and code, etc.

We have noticed that in addition to our commits that we make, Git also seems to create merges and check these in as well, see screenshot.

These commits are full of changes from other team members and so are only confusing to us an clutter our git history.

What are these automatic commits and is there any way to configure Git not to make these commits?

enter image description here

Edward Tanguay
  • 189,012
  • 314
  • 712
  • 1,047
  • Sounds like you're merging with `no-ff`, or `merge.ff` is false in the config. It looks like you're using some kind of UI wrapper around git, so you'll need to check its documentation for merge configuration. – William Pursell Apr 02 '21 at 15:26
  • But nobody is merging branches at all. We're simply updating files in each of our directories, pushing them as commits to the dev branch at GitHub and pulling commits from the dev branch from GitHub. We only work in the dev branch and so aren't creating branches or merging them back. What could be creating these "Merge branch 'dev'' of nnn into dev" entries? – Edward Tanguay Apr 02 '21 at 15:31
  • Given that it is branches from github merging into dev, perhaps someone is doing `git pull --no-ff` or has `pull.ff` configured to false. – William Pursell Apr 02 '21 at 15:38

2 Answers2

7

Your comment explains why this is happening:

We're simply updating files in each of our directories, pushing them as commits to the dev branch at GitHub and pulling commits from the dev branch from GitHub.

It's the pull that causes the merge commits. Presumably you are all checking out the dev branch, making your commits, and at some point pulling the latest. When you pull commits from the remote version of your branch and you also have new commits on your local branch, the default setting in Git will create a merge commit.

To avoid it, you have a few options:

  1. When pulling, use git pull --rebase. This will rebase your local commits onto the latest version of dev instead of creating a merge commit. If this is the way you decide to go, you can have everyone configure this to happen automatically.
  2. Don't pull anymore. If you want to update your local copy of dev, first do git fetch followed by git rebase origin/dev. The outcome is the same as #1, but this makes it more obvious that you are doing it.
  3. Similar to #2, you could start using separate branches instead of everyone working on dev. Before you merge into dev, do a git fetch followed by git rebase origin/dev.

Number 3 is probably the best way to go, but is a slightly more complicated workflow. But it enables task switching if you want to work on different things at the same time.

TTT
  • 22,611
  • 8
  • 63
  • 69
  • Hi, why is option 3 is better over oneliner option 1? – user1917451 Dec 21 '22 at 08:29
  • @user1917451 *Updating* a feature branch could still be a one-liner (but with more characters to type): `git pull --rebase origin dev`. As for why to use feature branches instead of sharing `dev`, some benefits might be: 1) if you need to task switch you can have multiple branches going at the same time. 2) If you want to collaborate with someone you can push your branch and someone else can code review it and/or use it before it's merged into the shared branch. 3) It enables using Pull Request functionality. (cont...) – TTT Dec 21 '22 at 14:44
  • (...cont) 4) It enables you to backup your code outside of your machine by pushing your personal feature branch until it's ready to be merged. All that being said, if you normally don't need any of those benefits, you could keep using `dev` and only name the branch to something else, on the fly, when you do wish to use one of those benefits. – TTT Dec 21 '22 at 14:45
  • Hi, im still confused. Im on a feature branch and when I need to update my branch from dev, I just use `git pull origin dev --rebase`. It works for me but not sure whats the side effect of this option. – user1917451 Jan 23 '23 at 02:53
  • @user1917451 When you say "what's the side effect", I wonder, compared to what? That's a fine way to update your feature branch with the latest code from `origin/dev`. – TTT Jan 23 '23 at 03:14
  • over this `git fetch` followed by `git rebase origin/dev` because you said this is best the option. – user1917451 Jan 23 '23 at 03:19
  • 1
    @user1917451 Oh, I see what you mean. They are (nearly) identical. I personally prefer doing separate `fetch` and `merge`/`rebase` commands, compared to using `pull` in a single command. The reason is I like to look at what I'm bringing into my branch before I do it. As for my preference of #3, I meant using a separate feature branch over everyone sharing `dev`, for the reasons I stated in the earlier comments. Regarding that preference of #3, I didn't mean that splitting `fetch` and `rebase` is also better than `pull --rebase`; that's just my personal preference. – TTT Jan 23 '23 at 03:29
  • @user1917451 This is getting into the weeds a bit, but basically `pull --rebase = fetch + rebase`, except for some rare instances, [such as this one](https://stackoverflow.com/q/66535801/184546). – TTT Jan 23 '23 at 03:35
1

Try using git pull -r to rebase your commits on top of the latest origin/master, instead of creating a merge commit. Although to create a proper workflow with your teammates you should use branches, this is a way to get rid of merge commits.

larsl
  • 338
  • 1
  • 10