0

We have a master branch m where we have a linear history and merge in typically relatively short lived feature branches F1, F2, ... like so:

*   343b52f - (11 days ago) Merge branch 'F495' into 'master' - Torque
|\
| * 52fc5a2 - (11 days ago) Add various QOL tools to make working inside Docker more convenient - Torque
|/
*   1eaa8df - (2 weeks ago) Merge branch 'F494' into 'master' - Boss
|\
| * 9758e64 - (2 weeks ago) Use company-php-commons as source for custom DQL functions - Boss
| * 2c8ee88 - (2 weeks ago) Upgrade to latest company-php-commons (for custom DQL functions) - Boss
|/
*   a1d7acc - (3 weeks ago) Merge branch 'F493' into 'master' - Coworker
|\
| * 149ead1 - (3 weeks ago) Update: Device Amount Calculation - Coworker
|/
*   f69c844 - (3 weeks ago) Merge branch 'F492' into 'master' - Torque
[...]

The feature branches aren't always this short; I didn't want to bloat the post too much. Now, we are planning a new, long living branch to implement better logging for debugging, LD. In that branch, we are going to put commits that improve logging in our existing code base, and we don't want to merge it into master every other day, instead merging it once its considered done.

We would like to profit from these changes (during development only!) in future feature branches Fn+1, but we don't quite see how - whether we rebase on or cherry pick from the unfinished LD branch, once we want to merge Fn+1 into master m, I see no way how LD commits will not make it into m prematurely.

Is there a way to 'temporarily' merge LD into Fn+1, and 'unmerge' LD before we merge Fn+1 into m ? As LD only contains code in the core product and Fn+1 will almost exclusively contain (logging) code in isolated classes, we don't expect to ever, or at least only extremely rarely, see merge conflicts and/or code path conflicts.

Torque
  • 3,319
  • 2
  • 27
  • 39

2 Answers2

1

To develop a new feature -

Checkout latest LD:

git checkout LD

Create a new feature branch:

git checkout -b f500

Do some stuff in the feature branch:

git add ...
git commit ...
git add ...
git commit ...

Now that you want to have these changes in master, perform a rebase:

git rebase --onto m LD

This will "move" your f500 branch as if it branched off of master.

Note however that if any of your f500 code depends on LD related code, it will not work properly, because the LD code is not in master, so make sure you never actually commit LD dependent code

Omer Tuchfeld
  • 2,886
  • 1
  • 17
  • 24
  • Thanks! Obviously, code dependency would typically be an issue, that's why I outlined our use case, as it's very unlikely to bite us in the behind here, with embellished logging statements. Not being familiar with `rebase --onto`, I found this question (and its answers) very helpful: https://stackoverflow.com/questions/29914052/i-cant-understand-the-behaviour-of-git-rebase-onto – Torque Aug 03 '20 at 08:59
0

The easiest way would be to manage to somehow commit the code in master.

You can still exclude it from your production releases ; depending on the language you use, you can :

  • explicitly exclude the directory debuglogger from your release tar.gz
  • explicitly exclude the code for class DebugLogger when compiling your code
  • ...

One hacky way :

project/
├── .git
├── debuglogger    # version debuglogger in a separate repo
│   ├── .git       # and clone it locally on the developers' laptops
│   └── sourcefile
├── dir1
├── dir2
├── sourcefile1
├── sourcefile2
...

If you clone debuglogger on your working machine :

  • running git commands from your main project will completely ignore this subdirectory
  • you would have to add a switch in the code of the project, to include the code from debuglogger if possible, something like :
    • if env = dev, include debuglogger
    • if DebugLogger class is available, load it
    • if debuglogger/ is present, include it in your compilation scripts
    • ...

When you deem your feature ready, you can include it in your main project, either as a single commit, or importing its history (for example using git subtree).

The hacky part of this setup is : it breaks the general git idea that "a commit should represent the whole project"

LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • I appreciate the effort you put into your answer, but it doesn't address our main concern of a linear history. The whole point is that we don't want to regularly merge the 'branch-in-progress' into master. – Torque Aug 04 '20 at 07:51