4

I have a project where I am the only developer, with develop and master branches. Every time I merge develop into master, I'm getting an extra merge commit. I think this is because it is not doing a FF merge for some reason. But the code in the develop and master branches is identical. I'll add a new feature to develop branch, often one commit, then after testing merge it to master. And every time I'm getting these extra commits (which also makes develop branch look like it's 15 commits behind master).

I have a few other projects I'm running the same way, and I'm not getting the extra commits on those. So it appears I've done something to this project to cause it to create these extra merge commits every time. Any idea how to stop getting these extra commits? I've done everything except blow away the develop branch and create it again from current master.

Bonus question, is it possible to clean up the history by essentially removing the merge commits without squashing or removing the additional commits accompanying them? I've considered blowing away the MASTER branch and creating it again from develop (since it doesn't have the extra commits) but I'm not sure that's a good idea.

enter image description here

Improve this question
5
  • 1
    Nowadays even big teams are trying to use trunk-based development. I'm curious why 1-dev team would have 2 branches :) Commented Dec 9, 2019 at 17:32
  • Well in the future we'll probably have an entire team of devs working on bots across the Enterprise. But mostly I'm just trying to figure things out right now. My initial thought is that we would use the develop branch more like a trunk and go to master branch by way of PR. There's some testing that I can't do locally for a variety of reasons so it helps to deploy to Azure without impacting master branch. Open for other suggestions, @StanislavBashkyrtsev! Commented Dec 9, 2019 at 19:01
  • You can google Trunk-Based Development - there's plenty of good articles on how to implement it. Basically you just have 1 branch - master and that's it. If you're not ready for this you could create short-living branches to stash portions of code for a day or two and make PRs out of them. If you're not ready to this either, you can try working in feature branches (and finish whole features there). Overall advice - just keep it as simple as possible with as little code in branches as possible. PS: you won't be able to create PRs from develop if the whole team pushes to develop. Commented Dec 9, 2019 at 19:14
  • IF we understand that all changes in the development branch go with a PR, that still works, no? This is perhaps ill-advised, but we don't have access to deploy to Azure through DevOps, so the only way to enforce our tests to run is to do a PR and allow the merge only after that. We have CD from master branch to Azure directly on the bot service, and if we merge and push directly to master branch it gets deployed to Azure no matter what. I think if we could do 100% local testing using only master might work, but I'd rather have someplace to deploy the code first to test before pushing to master Commented Dec 9, 2019 at 20:43
  • 1. You should be able to deploy and test things locally 2. Your team will probably want to run tests frequently and each team member would want to do that separately from others. You can achieve this if everyone creates small PRs for their changes only. Commented Dec 10, 2019 at 5:54

2 Answers 2

Reset to default
5

You can only fast-forward master to develop if develop is "based" on master (by going back from the commit develop points to it should be possible to reach the commit master points to).

Looking at the picture, it is very likely that at the moment master points to 28b73893 but develop is still at aeb743f1. If you make a commit in develop, the fast-forward will not be possible.

To solve that, merge master back to develop. This will be a fast-forwarding merge. After that, master and develop will point to the same commit; and it will be possible to make a commit in one branch and fast-forward the other branch.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

You are right, master is at 28b73893 and develop is aeb743f1. But the changes are exactly the same! I made my changes resulting in commit aeb743f1, the merged them into master, and at that point 28b73893 was created. I guess what I'm trying to figure out is how to merge aeb743f1 (in this case) into master without having that extra, useless merge commit.
Additionally, develop branch doesn't have ANY of the merge commits in the history, so they all make the develop branch appear "behind" the master even though the code is exactly the same at this point.
Clearly somehow I got an extra commit in there with (almost) identical changes. Your answer most closely fixes my issue by getting the branches synced back up and keeping things cleaner from there. But I do appreciate @KhalilKhalaf's answer on rebase, as that has come in handy to fix issues like this with extra commits. Thanks to both of you.
2

You need to use the rebase command.

If you want the history of your branches to look linear, what you want to do is:

  • Commit on Development branch: git commit -m "FeatureX on Dev"
  • Rebase with up-to-date master: git fetch origin master:master, git rebase master
  • Test your code
  • Happy? Rebase master onto Development and force-push: git checkout master, git rebase Development, git push -f

PS: Rebase is dangerous since it rewrites the history of the branch (steps 2 and 4 above), unless:

  • You know exactly what you are doing
  • No one else pulled the old history

For both, you should be good.

Specific to Azure-Devops:

Under Repo->Commits, if you click on the filter icon and choose "First Parent", it will hide the merges automatically. Try and see if Github has the same?

enter image description here

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.