Project sources have multiple conditionals that used to only test many different scenarios, but such logic should never slip to production-ready state of the code (it's a requirement).

Thus, when I need to develop new "feature", I take "production", apply "test" changes on top of it, implement the "feature" by typing in the new logic and when tests pass (some auto, some manual), remove "test" changes and then commit "feature" to "production".

Are there any Git practices that might assist in that?
Everything I've tried: worktree, git merge --no-commit, patch.

Project sources have multiple conditionals that used to only test many different scenarios, but such logic should never slip to production-ready state of the code (it's a requirement).

Thus, when I need to develop new "feature", I take "production", apply "test" changes on top of it, implement the "feature" by typing in the new logic and when tests pass (some auto, some manual), remove "test" changes and then commit "feature" to "production".

Are there any Git practices that might assist in that?
Everything I've tried: worktree, git merge --no-commit, patch.

• git
• git-workflow

• There is no fully automated way to do this. If you want to cherry-pick your "test changes" commit on top of your implemented feature branch, there is always a risk there may be a merge conflict, and you will have to resolve that manually. – Alderath Commented Mar 6 at 13:30
• 1 What about a simple git cherry-pick --no-commit test (if all your changes are in the last commit of this branch. If not, replace cherry-pick with merge, the principle is the same), test what has to be tested, then git cherry-pick --abort? – Romain Valeri Commented Mar 6 at 13:45
• 3 Production-only code/config should be managed through code and config. Like with feature flags. Git is way too primitive to do that job. “The Stupid Content Tracker” – Guildenstern Commented Mar 6 at 13:58
• 2 “is even more complicated, but”—that there are supposedly complicated commands is not the point. It’s the use of such tools which makes it complicated. A normal project managed by the same team will typically have the version of the code on the main branch. Not a “prod” and a “test” version. If you have two versions you at least double the version control work. Concretely people use git-rebase for in-progress work. They don’t (on the same project) use it to continually rebase something on top of “test” and “prod”. – Guildenstern Commented Mar 6 at 17:29
• 2 ... When this happens (that you have to rebase on top of ever-changing code) is when you don’t own the code but might be applying changes that you want but not the upstream project (so it’s not just “one team” any more). And that kind of situation is driven by necessity since it is much more preferable to just get your own changes integrated into the upstream project. So when someone asks how to do the same thing in a single-team environment? That’s just a red flag. – Guildenstern Commented Mar 6 at 17:31

1 Answer 1

I'm not quiet sure I understand your question correctly. But if I do you should be able to utilize git rebase for this.

So, if I understand correctly you want to track some code for testing that should never be included in the branch which is used for production. While developing a new feature you need that code to be present but when merging the new feature to the production branch it should not include the (commits with) test code.

For this you would need three branches:

• production holding the code to be deployed to production
• tests consisting of the same code as production + the additional test code
• feature consisting of production + tests + new commits for the new feature

In the beginning these branches can simply build on top of each other:

o---o---o  <-- production
         \
          T1---T2---T3  <-- tests
                      \
                       F1---F2---F3  <-- feature1

Where the commits T1-T3 introduce the test code you don't want to be part of production. When starting a new feature branch feature1 it is first the same as tests and then you add the commits F1-F3 for the new feature to it.

When you are done with development you can now rebase the commits of frature1 on top of tests back on production, see git rebase --onto:

# while on branch feature1
git rebase tests --onto production

which will result in

o---o---o  <-- production
        |\
        |  F1'---F2'---F3'  <-- feature1
         \
          T1---T2---T3  <-- tests

Now you can just merge/fast-forward production to feature1 with

git checkout production
git merge feature1

which will result in

o---o---o---F1'---F2'---F3'  <-- production, feature1
         \
          T1---T2---T3  <-- tests

So now you have all the new feature commits of feature1 included in production but the commits T1-T3 are still in their own branch.

For the next feature you can then do the same with a new branch feature2 branching from tests again. But first you need to include the new feature commits in tests which you can either do with git rebase tests on production or git merge prodcution:

# on branch tests
git rebase production

which will result in

o---o---o---F1'---F2'---F3'  <-- production
                          \
                           T1'---T2'---T3'  <-- tests
                                         \
                                          F4---F5---F6  <-- feature2

or

# on branch tests
git merge production

which will result in

o---o---o---F1'---F2'---F3'  <-- production, feature1
         \                \
          T1---T2---T3-----o  <-- tests
                            \
                             F4---F5---F6  <-- feature2