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).
GIT CREATE NEW BRANCH 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 kommentar(er)
