0

Problem: We need a test environment that can use the same database for different code changes without having to have the code to support all the different database changes.
Things sometimes break because the code and the database are not in sync (ex: can't find column)

Here's an example of my solution to the problem that I can't properly describe, which has its own problem at the end:

We have these branches:
Develop
Team_branch
New_Feature_Branch

Main_Test_Environment uses Develop branch which uses Main_Database
Team_Test_Environment uses Team_Branch which uses Team_Database

Once New_Feature_Branch is finished it is added to Team_Branch to be tested on Team_Test_Environment

Let's say New_Feature_Branch is all good to go live. How do we get New_Feature_Branch into Develop branch without all the changes from Team_Branch?

This would be easy if we didn't need the Team_Branch changes in our New_Feature_Branch to begin working on it:
New Feature from Develop -> Finish Feature -> Merge into Team_Branch -> Was approved -> Merge feature into Develop.

Done. However because we're using a different database and need to have our code and database synced, we NEED to start like this:
New feature from Team_Branch -> Finish Feature -> Merge into Team_Branch -> Was approved -> Merge feature into Develop.

BAD AND WRONG
Now we have all the Team_Branch changes in Develop branch when we only want the New_Feature_Branch!

How do we solve this?

EDIT in response to merge-base as a solution:

I tested it out, but unfortunately it seems like it won't do the job. Because:

Feature_1 created from the merge-base -> finished feature -> merged into Team_Branch to be published for testing.
Feature_2 created from the merge-base -> Error! Because Feature_1 changed stuff on code and database and we don't have Feature_1 commits but we're using the same database.

That's why starting from Team_Branch is necessary (I think?) to have the latest changes and not have to create a new database.
And I do want to keep Team_Branch as up to date with Develop as possible, so I will be merging Develop into Team_Branch often.

Karolis Vaitkevicius
  • 310
  • 1
  • 5
  • 14
  • In general, you revert the unwanted merge (perhaps the end one, perhaps just the intermediate one). This has consequences. There are lots of existing SO answers about this; read them. – torek Mar 19 '22 at 02:10
  • Do you really *need* to start like this: "New feature from Team_Branch" ? Could you instead start from `git merge-base Team_Branch develop` and then that branch could potentially be cleanly merged into either? – TTT Mar 19 '22 at 03:36
  • Also, do you periodically reset `Team_Branch` to `develop`? If no, this would help you, and is what many repos do (including Git itself- the equivalent of your `Team_Branch` is called `next` and it is periodically reset.) – TTT Mar 19 '22 at 03:40
  • @TTT That is a cool command! I wasn't aware of it - thanks. I tested it out, but unfortunately it seems like it won't do the job. I replied to you as an edit to my post to help with formatting, hope you don't mind. – Karolis Vaitkevicius Mar 20 '22 at 00:18
  • @torek Can you point me to these SO answers? I searched and couldn't find anything that was dealing with something similar to my case. Maybe I just don't know what to search! – Karolis Vaitkevicius Mar 20 '22 at 00:19
  • https://www.google.com/search?q=site%3Astackoverflow.com+git+revert+faulty+merge turns up a bunch, though the first one is not good. The [second](https://stackoverflow.com/q/47596296/1256452) and [third](https://stackoverflow.com/q/8323029/1256452) are better and it goes on and on from there :-) – torek Mar 20 '22 at 01:59
  • @torek Thanks for the reply, I've looked through them. I tried to implement them but I think there's a wrong assumption that it's a "faulty merge". It's not, I deliberately want this merge to happen and there will be new features developed FROM this merge (Team_Branch). The problem arises when I want to merge into Develop JUST the changes from Feature and not the changes from Team_Branch - even though the Feature was worked on top of Team_Branch. At this point I'm not even sure it's possible without getting insanely complex. See my reply for merge-base solution. – Karolis Vaitkevicius Mar 20 '22 at 14:54
  • It doesn't matter whether the merge is "faulty" or not: what matters is just what's *in each snapshot*. If you don't like what's in the snapshot (of some commit), you make another commit. You need to understand what the tool—in this case, Git—does for each operation, too: merging, as in running `git merge`, is about combining changes. Yet a commit holds no changes: each commit *is* a snapshot (of all files) plus some metadata, and nothing more. Git gets "changes" by *comparing snapshots*, so `git merge` is about comparing certain commits' snapshots and turning those into changes and [cont'd] – torek Mar 21 '22 at 00:35
  • ... then combining the changes obtained by these comparisons and applying the combined changes to a snapshot (the merge base's snapshot). Once you understand this, plus the fact that a *branch name* just lets you find a specific commit and easily add new commits, you'll reach the Zen of Git as it were. See also http://think-like-a-git.net/ for key insights. – torek Mar 21 '22 at 00:37
  • @torek Oh that site seems pretty nice! Thanks. I'll keep on researching and see if I can adapt some solution to my problem. – Karolis Vaitkevicius Mar 21 '22 at 23:45

0 Answers0