On Sun, Aug 29, 2021 at 3:51 AM SJW <shannon.whi...@gmail.com> 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/CAM2wTFZ0OBJF3D-xMf0zrew4AgJRrRqz65E1rHsAbMagzgnyGw%40mail.gmail.com.
