0

I have a webpage which I've been working on, and have something annoying with git merges which I was wondering if there is a non-rebase workaround for.

Essentially the production branch required an additional file to be added to the repository as some extra configuration for production only. It is a completely new file, and with no conflicts etc.

Ever since, whenever merging the dev branch to production, you get the merge-commit message. Previously it could always fast forward. Typically commits are not made to the production branch save for the merges from dev branches.

Is there any way to prevent this without doing rebase on the dev branches to include the unneeded extra file, some form of merge flag perhaps?

Derpy Derpster
  • 1
  • Why are you against doing a rebase? And if the file is unneeded, why is it in production? If the file is in production, it affects the application which means anything your developing which has an aim to going into production, would need that file in your project to fully and properly match the production release. – Harmelodic Mar 17 '16 at 01:25
  • It is not that it is unneeded, it is that in dev environment it isn't strictly required. It is a node app running on IIS in Azure, and production has SSL enabled, so there is an extra config file required for production. Typically dev is not running full IIS server, so it's not strictly needed in dev. Was curious if there was any way around it that's all. In reality should probably do something using Grunt or similar, but that's another part in an already steep learning curve with no time or dev resources to spare. – Derpy Derpster Mar 17 '16 at 07:55
  • Your DQP process/setup should be consistent all the way through. If SSL is enabled in production, it should be enabled in QA and Dev too. What if you developed something and it worked in Dev, worked in QA and then you deployed to production and it lost functionality because SSL interferes with it? In fact, how do you do proper integration testing in QA without SSL enabled? Environments should be consistent. The minimum you should have running in QA and Dev is whatever you have in Prod, then you can add in any extra software that you need to develop features. – Harmelodic Mar 17 '16 at 09:31
  • While I don't disagree, my original question was around git and git merging. Is it a case where if there are any changes downstream, any merge from any other branch will include a merge-commit change regardless of whether there is any overlap in changed files, and there is no way around it other than rebase? – Derpy Derpster Mar 17 '16 at 22:19
  • 1
    [My understanding of your situation](http://imgur.com/B3XPdF6) is that you're developing your application to be environment specific depending on the branch. However, especially when working with the self-contained nature of Node.js, a VCS is just for your application and not for anything environment specific (Hence my comments about about your DQP process/setup). Rebasing would remove your merge-commit issue, make you Git history cleaner and stop your application from being environment specific. [Please read this as a merge/rebase guide](http://bit.ly/1R3KFbS) – Harmelodic Mar 18 '16 at 10:43

1 Answers1

0

Not really.

The rebase is what makes a fast-forward merge possible in the first place.

So if you want all the commits in your dev branch to be included in your production branch and you don’t want a true merge (a merge commit) then you need to do a rebase.

If you just want the changes from the dev branch in one commit then you can do git merge --squash, which won’t produce a true merge.

A merge commit without a merge message

If you just want to avoid a merge message specifically then you can do this:

git switch production
git merge --no-edit dev
git commit --amend --allow-empty-message -F /dev/null
Guildenstern
  • 2,179
  • 1
  • 17
  • 39