1

I have a common git workflow, where you have two main branches: develop (for development) and master (for production). All other branches are created from these two and then merged back.

Normally, when there is a bug on production, I create a branch bugfix-*version* from the master, and than I merge it back into master. But I need to merge it also to develop branch to apply this "patch" to all future development as well.

But there are some differences in the code on production and development branches, mainly related to different environments (DB credentials, some variables, paths, etc).

  • Now to the problem :

When I merge bugfix branch (that was created from master) into develop it doesn't take only the diffs that were presented in that branch, but also all that specific branch-related and environment-related information that is different between the branches.

I could use cherry-pick to pick only diffs for each commit, but it would mean to copy every single commit from one branch to another. It's messy and doesn't preserve the clean history of changes.

I could use a post-merge script or somewhat to automatically change the differences between the environments, but it seems too difficult and bug-prone.

Or I could probably merge without committing, then manually correct all values, and afterwards commit... It seems to be such a common task, that I'm sure there must be a way, some sort of merge strategy, or I don't know what, to solve this problem with the power of git without any workarounds! Or maybe I misunderstood some conceptions and I shouldn't really try to merge these branches?

Thank you in advance!

Example

       DEV branch                      |               PROD branch
                                       |
                             Differences between branches
1. $environment_path = "/www/dev";     |     1. $environment_path = "/www/prod";
2. $db_name = "some_name";             |     2. $db_name = "other_name";
...                                    |     ...
                         The modified lines (new commits)
200-205. "some old lines with a bug"   |     200-205. "bugfix"
...

So what do I need is to be able to merge modifications from one branch to another without touching those first lines. "the rest of the script"

GZstudio GZstudio
  • 85
  • 10
  • Could you, please, give a more concrete example with schema, screenshots, some code...? – Supersonic Jan 10 '22 at 16:06
  • 1
    "But there are some differences in the code on production and development branches, mainly related to different environments (DB credentials, some variables, paths, etc)." --> is the reason for which these things are usually kept out of versioning by the virtue of .gitignore files. Cherry-picking could be a workaround, yes, potentially slightly time-consuming, but... messy? Why would it be? – Romain Valeri Jan 10 '22 at 16:20
  • 1
    Could this be an x-y question? How do you know that "some sort of cherry-pick strategy" is right? Wouldn't it be better to give the actual situation and ask in an open-ended way for solutions? – matt Jan 10 '22 at 16:27
  • 1
    Also, question: how do you merge from develop into master? True merge, or some sort of fake-merge thing like squash? – matt Jan 10 '22 at 16:28
  • @matt First I create a pre-release branch, than I manually change everything, I create another commit and then I merge into master. I don't know another way. – GZstudio GZstudio Jan 10 '22 at 16:36
  • 1
    @RomainValeri There exist a lot of articles about why you should not use cherry-pick. Without going too into details, it's messy mainly cause you should COPY every commit (It creates another commit in git tree, just a duplicate), you can't subgroup commits like with merge --no-ff and you don't have any relation to the branch from which these commits arrive. – GZstudio GZstudio Jan 10 '22 at 16:41
  • 1
    @matt, "Wouldn't it be better to give the actual situation and ask in an open-ended way for solutions?" You mean just to rename the topic? – GZstudio GZstudio Jan 10 '22 at 16:43
  • 1
    Suppose you have a `hotfix` off of `master` with 3 commits that fix some bugs. Would any of those 3 commits *normally* change any of the environment specific stuff also? If yes, would those env-specific changes be in their own commit, and then perhaps the other 2 commits could be cherry-picked, or would the env-specific changes be mixed in to a commit with other changes you need merged back into `develop`? (Or is it: *normally* environment specific changes are *not* occurring in a hotfix, but could happen occasionally.) – TTT Jan 10 '22 at 21:43
  • 2
    See [Stop cherry-picking, start merging](https://devblogs.microsoft.com/oldnewthing/20180323-01/?p=98325) – torek Jan 11 '22 at 04:18
  • @TTT Normally, NO. The modifications I make (the diff lines) do not touch that env-specific stuff. But these env-specific lines were already different on **master** and **develop** even before the creating of **hotfix** branch. So I would like to merge only changes made but not all the differences that existed before. – GZstudio GZstudio Jan 11 '22 at 11:36
  • In my opinion, nothing stops you from having two parallel projects, one, Dev, with all the old changes and, two, the Prod with clean commits. I do not see the utility, though, because the very sense of Git is to see in what changes you improved your code and what version you have chosen. Hence the word Versioning Tool..., not presentation tool. I am against cherry-picking too. Thanks @torek (@GZStudio GZstudio please stop mixing "than" with "then"...) Happy coding ! :-) – Supersonic Jan 21 '22 at 15:50

0 Answers0