12/31/2023 0 Comments Git rebase on another branch![]() ![]() At this point, it would be wise to rebase the feature_yyy_frontend branch onto master, so that the reviewers only need to review the new changes that this branch contributes to master, and not need to re-review the changes made for the backend (which have already been approved). Once the review of the backend branch is completed, it gets merged into master. because there are things that come up during review that need to be adressed, simply do these changes and merge them into the feature_yyy_frontend branch. When the feature_xxx_backend branch changes, e.g. then simply develop the frontend feature asif the branch were master. You will probably want to branch directly from feature_xxx_backend, so that you have those changes already in your branc. So, simply start another branch, feature_yyy_frontend. When this is done, the branch is up to review and will be merged into master once the review is complete. So, in your concrete example, you first create the feature_xxx_backend branch and develop the backend changes. You already have this every time with your master branch, which keeps changing while features are developed and then merged. ![]() But as I can see it would be more likely to pause the frontend work until you'd figure out what was going to replace the backend you're throwing out, and then decide what to do. If it turns out that the whole backend branch needs to be abandoned and will never be merged (it sounds like this would be a pretty major deal that would rarely happen), then you either cherry-pick your commits to a new branch coming off master without the backend work, or you apply reverse commits that remove all the backend code to the frontend branch. This is easy if you're the only developer doing both features (since you know if you yourself make any major changes), but even if both features end up being worked on in parallel by different devs it should be fine you just have to stay in communication (which you would need to anyway, if you're working on tasks in parallel where one has a critical dependency on the other). If it turns out the backend branch needs a lot more work and it continues to change over a period of time before being merged to master (say if major problems are found during review), then you you'd probably want to do periodic merges directly from the backend branch into the frontend branch (so you don't keep basing all of your frontend work on obsolete backend code). So you do that on your front end branch, and when the backend work has been accepted to master, you'll get any minor changes that were made to the backend as part of its review/acceptance automatically, by the same route you'd get any other code changes on master. In this case where the frontend task has a critical dependency on the backend code, and you want to start work on the frontend before the backend is finalised and accepted on master, I would simply start the frontend task as a feature branch coming off from the backend branch, rather than branching the frontend on master.Ī feature branch that lives long enough needs to merge in changes from master occaisionally (to make sure you to reconcile any merge or semantic conflicts as part of dev work on the feature branch, rather than as part of the "review, qa, merge-to-master" process). Do not make it in two different commits in both branches, even if may be tempting as feature_a is part of the history of feature_b, having the single change in two different commits will be semantically wrong and possibly lead to conflicts or "resurrections" of unwanted code, later. Your feature_b is now a simple, standard branch going right from master.ĮDIT: inspired from the comments, a little heads up: if you need to make some change which affects both features, then be sure to make it in feature_a (and then rebase as shown). This final rebase will graft all commits that are dangling from the feature_acommit (which is now irrelevant as it has been merged into master) right onto master. Git rebase -onto master feature_a feature_b ![]() įinally, as soon as feature_a has been merged into master, you simply get the new master and rebase feature_aonto it a last time: git checkout master Whenever feature_a changes while it is waiting to get merged into master, you rebase feature_b on it. Start your feature_b from feature_a, i.e.: git checkout feature_a Rebasing has been mentioned in other answers, but only for rebasing things onto master. For this approach, you do not want to merge your feature_a into feature_b repeatedly. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |