I am a lone developer so it is pretty straight forward to merge and rebase.
Nobody touches git except me.
Is there a benefit in rebasing over merging? e.g. working in feat-2 which I
realise needs some code from feat-1 - I can rebase OR just merge. I guess I
do merge all the time so I can
Just stop the dumb shit before u regret your actions. Mase;)
On Wed, Sep 1, 2021, 9:44 AM Philip Oakley wrote:
>
>
> If you can avoid branching feat-2 from feat-1 then that is worthwhile if
> if allows an independent feat-2 to be released while feat1 is still in
> test. However if there is some
If you can avoid branching feat-2 from feat-1 then that is worthwhile if if
allows an independent feat-2 to be released while feat1 is still in test.
However if there is some shared code, then it's worth branching earlier
within feat-1 before the feature-1 visible changes show up. It is there
Thanks to both of you for providing such detailed, in-depth responses.
Your assumptions were correct. I branch per feature. I have actually
branched a new branch (feature-branch-2) from another feature branch
(feature-branch-1) once but then I wasn't sure if it was logically right
because
On Sun, Aug 29, 2021 at 3:51 AM SJW wrote:
> I will regularly create feature branches for each new enhancement or fix.
> The problem rears its head when testing is delayed and the first feature
> (feature-branch-1) is still not approved for production and sits as a
> branch awaiting merge.
>
>
I have been Watching YouTube tutorials in order to expand my knowledge in
git but there are now some questions that this has raised so I was hoping
someone here could educate me on some best practices or philosophies I
should consider.
The main point is around rebase - I see great value in
