Nice post!
But i do hv a questions on feature -> release
in one of my new project
i expect some features will only be POC and may never implement into production
but user still want to test it first
my current approach is to create a develop branch which act as a UAT environment for user to test out features if feasible or not and only merge into release if they feel good about it
is it a good approach or not?
The only catch is that it works very well for independent features. But if you have dependent features then we had to deal with it by manually changing the code. Still figuring out the best way of handling this
actually i think there may be a issue..
variation of develop and release will become greater and greater
and at some point, we may be forced to merge release into develop
just to get things a bit easier to work with..
hv any ideas about it?
maybe rebase can do the trick? but im not familiar with it
Rebase is generally used to update the code in local with the latest code in remote. Using Rebase in the remote can create issues since it overwrites history.
I guess one option is to handle it in the code itself rather than trying it with git. You can have a config to say which features to enable and disable.
So when users say they don't want a feature, you just go to the code config and disable it. In the future, they may want the feature back. In that case go to the config and enable it :D
I think having a config like that makes it easier than handling it with git. What is your take on this?
Nice post!
But i do hv a questions on feature -> release
in one of my new project
i expect some features will only be POC and may never implement into production
but user still want to test it first
my current approach is to create a develop branch which act as a UAT environment for user to test out features if feasible or not and only merge into release if they feel good about it
is it a good approach or not?
Thanks!
I Have been in similar situations :D
I did exactly what you have mentioned.
The only catch is that it works very well for independent features. But if you have dependent features then we had to deal with it by manually changing the code. Still figuring out the best way of handling this
actually i think there may be a issue..
variation of
develop
andrelease
will become greater and greaterand at some point, we may be forced to merge
release
intodevelop
just to get things a bit easier to work with..
hv any ideas about it?
maybe rebase can do the trick? but im not familiar with it
Rebase is generally used to update the code in local with the latest code in remote. Using Rebase in the remote can create issues since it overwrites history.
I have written about rebase as well. You can check it out here
adityasridhar.com/posts/how-to-bec...
I guess one option is to handle it in the code itself rather than trying it with git. You can have a config to say which features to enable and disable.
So when users say they don't want a feature, you just go to the code config and disable it. In the future, they may want the feature back. In that case go to the config and enable it :D
I think having a config like that makes it easier than handling it with git. What is your take on this?
omg😲
using config file is a brilliant idea!
why i hvnt thought of this before!
i know rebase will overwrite the history, maybe i will just stick to local rebase first
Thank you!😘