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.
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
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:
debuglogger
from your release tar.gzDebugLogger
when compiling your codeOne 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:
git
commands from your main project will completely ignore this subdirectorydebuglogger
if possible, something like:
env = dev
, include debuglogger
DebugLogger
class is available, load itdebuglogger/
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"
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.