Hi Shannon, Some thoughts: first a bit of cod-philosophy : we can't control or 'manage' change, all we can do is administer it, and add a bit of political spin ( Situation, Problem, Implication, and Need-payoff ). Lot's of managers think they have control, but we all know.. Git with it's 'DVCS' distributes that 'version control' to the coder (because we can locally create versions/revisions to out heart's content). This separates the recording of versions from the inclusion (merge) into the main/golden repo. I raised that to highlight the shift in the focus that can be applied. (I remember the smell of a real 'blueprint' machine!, and microfiche on IBM Hollerith cards.. the horrors of history;-)
It is worth looking at the different approaches to including code and changes, and where they came from. Most administrative methods have developed over the last century (yes) from the way that old style drawing offices controlled their 'drawings' used for the manufacture of hardware (think Titanic master drawings - no drawing, no ship). Those are the same, conceptually, as software code. They both require tools to take the information to create product. We now uses compilers rather than lathes (see CNC machines as missing evolutionary link). They managers would batch up changes to the drawings (no touching the master, it was too precious), which is now the 'squash everything together' approach. Each of the different approaches to merging and trunk development come out these historical experiences (monkey stepladder stuff) Others would keep better records of the small changes, so they could see *why *faults happened later, especially if they did prototype testing. That's your current problem. You have a batch of changes, and a prototype is being tested. Meanwhile others have also being adding changes, and you might "need to consider changes from feature-branch". Some of this is a social issue of conflict/collaboration and negotiation, so that you could split out independent changes from (potentially) inter-related changes. This would allow your *individual changes to be re-ordered* to have the independent changes first and the (potentially) interrelated changes (aka 'conflicts') put near the end of the rebase sequence. With this split you can split the testing into the two parts. Being able to add the independent changes early gives a firmer base for the interrelated changes and helps clarify the core element of the change. Often we can't see the woods for the trees in the feature branches. There is nothing to stop you from *doing a trial merge* of your 'released to test' branch with the 'alt-feature' branch just so that you can, in advance, know which 'conflicts' are just awkward context changes (the context lines don't line up), which are order dependent within the resolution, and which are wholescale syntactic changes. It's the last group that need the active social action to convert that idle time to useful prep time. The former just need their resolutions recorded (unfortunately the `rerere` isn't easily exportable) so that whoever merges the features can resolve them with a single click. (one is assuming that testing is going to be successful...) On Sunday, August 29, 2021 at 1:51:19 AM UTC+1 SJW wrote: > 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 this but the whole > philosophy was around bringing committed code into your feature branch. > > 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. > > Now, in my feature-branch-4 I am working In a similar area and really need > to consider changes from feature-branch-1 and I usually just copy some of > those changes over. > > Now this is not very efficient and I thought rebase would work great BUT > that code is not approved and may actually change. > > I really just don't know what's the most efficient way to manage > situations like this without stopping development and waiting for testers > to approve code but this approach results in 1-2 days of waste where I just > twiddle my fingers waiting... > > Any advice or personal experience would be welcome. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/26653e02-b7b9-4445-aee2-13835bda112an%40googlegroups.com.
