Just stop the dumb shit before u regret your actions. Mase;) On Wed, Sep 1, 2021, 9:44 AM Philip Oakley <philipoakley@iee.email> 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 shared code, then it's worth branching > earlier within feat-1 before the feature-1 visible changes show up. It is > there that a code move rebase may be valid (must end up 'treesame' to the > code in test), just so you gain that starting foothold. > > rebase --squash is useful for minor corrections and mistakes, but it (from > my perspective) is poor practice to simply squash everything into the > classic "big ball of mud" change - that's also a hang-over from drawing > office procedures, and legal wanting to avoid 'discovery' (which is why you > rebase early & often, but retain a clean history ;-). > > How is the team, management, and the servers organised? This can affect > how you can get the best workflow. Do you have independent forks on the > server, or does every one have commit privilege to the golden branch > (separation of concerns..)?. Is there a 'maintainer', who does that final > validation for the merges and tagging of releases? Is this an entirely > software product - is it GUI style, or hardware control or database > manipulation, etc. (who else has fingers in the pie who aren't > coders/devs). Is it a run fast and break things shop, or a steady as she > goes, no icebergs shop? > On Tuesday, August 31, 2021 at 12:09:06 AM UTC+1 SJW wrote: > >> 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 now, feature-branch-2 actually has 2 projects or features and it is >> entirely possible for feature-branch-2 to be approved for production before >> feature-branch-1. Not a major problem I guess because I can just leave it >> unpublished until they are both approved however, just wasn't sure if I was >> following good practice. >> >> And then, new changes to feature-branch-1 - I thought - do I just apply >> them into feature-branch-2 and make this the single release no longer >> requiring me to manage 2 branches... Your comments have given me some food >> for thought. I will do a bit more rebase research I think >> >> I did look at rebase --squash and thought it was an idea given the >> numerous commits I might have in a branch but, I was concerned about losing >> history and wasn't sure the benefit outweighed the detriment so your >> comments have solidified my thinking on this. >> >> There's a bit to unpack in the responses so I will get acquainted with >> these suggestions. >> >> Any recommendations on learning would be appreciated too - if you have a >> YT video or text or something else that covers the common usage patterns I >> am interested in learning. >> >> On Tuesday, 31 August 2021 at 02:32:26 UTC+10 Mikko Rantalainen wrote: >> >>> 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. >>>> >>>> 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... >>>> >>> >>> I'm assuming you're already able to commit logical changes, not files. >>> If that's not true, learn that first. >>> >>> I'm also assuming you're doing real feature branches instead of having a >>> single branch per developer. >>> >>> The way I do it is to assume that whatever code my current branch >>> depends on is going to be blessed in the future. Or at least the internal >>> APIs that I use do not change and the problems are just in the >>> implementation of those APIs. So logically I just branch my next feature on >>> top of the non-blessed previous branch X. >>> >>> When testing/QA finds something wrong in branch X, it will be fixed as >>> new branch X' and I just rebase my branch from X onto X' (see "git rebase >>> --onto"). >>> >>> If you mix bug fixes and features in your feature branch, the simplest >>> way is to just "git rebase -i" your own branch and reorder/push all the bug >>> fix patches towards the already blessed commits (that is, make the >>> DAG/"history" appear like you did all the bug fixes first and all the >>> feature stuff after that). That would allow getting those included in the >>> blessed master(?) branch sooner (simple and minified bug fixes should be >>> obvious and easy to verify). Logically you would have an implicit branch >>> called bug-fixes that follows the blessed code and your feature branch then >>> builds on that implicit branch. >>> >>> Note that whenever you rebase or merge any code, all the testing done on >>> the old branch is of dubious value because of unforeseen interactions with >>> the combined code. That's why I prefer to do automated testing that's >>> included in the feature branch so that you can easily re-run the tests >>> after the merge/rebase. >>> >>> And never ever do squash merge/rebase, that just loses history. If you >>> want to make it easier to understand that some sequence of commits should >>> be considered an inseparable unit, do a "bypass" next to it with "git merge >>> --no-ff". That way your bypass commit will be equal to squash commit but it >>> will have a parallel line with all the original commit details. I prefer to >>> do such bypass merges only for the blessed/master version but if you want >>> to do it early, you will need to do "git rebase -p" from that point forward >>> which will make things more awkward. >>> >>> -- >>> Mikko >>> >>> -- > 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/eba339b6-ec9e-4c31-a492-81f668da752cn%40googlegroups.com > <https://groups.google.com/d/msgid/git-users/eba339b6-ec9e-4c31-a492-81f668da752cn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAPhpENXAaAsBqcrqsh%2Bd1NFN3VYyrNCmp6SGHFwdt%2BwDFes7DQ%40mail.gmail.com.
