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/a1f136f2-8efa-44c8-88e7-0938d75bfad5n%40googlegroups.com.
