![]() ![]() When should I use rebase?Īs its name suggests, rebase exists to change the “base” of a branch, which means its origin commit. ![]() In both these cases, we will always use merge, never rebase. This would be the default result if the receiving branch (say master) had moved ahead since we branched out, but if it remained untouched, we will need to prevent Git from using its fast-forward trick. It is then preferable, perhaps even mandatory, that the entire extent of our branch remain visible in the history graph. Our branch may represent a sprint or story in our agile methodology, or an issue/ticket in our bug tracking system. Is it a “well-known” branch, clearly identified by the team or simply by my work schedule? Then we turn our previous reasoning on its head. But if master remained untouched since we branched out, a fast-forward merge (which would be automatic in that situation, by default) will be sufficient. If the receiving branch (say master) has moved ahead since the branch started, and is therefore not a direct ancestor of it anymore, we’ll treat our branch as “too old” and use rebase to replay its commits on top of our up-to-date master to maintain a linear graph. Is it just a local, temporary branch, that I had just created out of precaution, in order for master to remain clean in the meantime? If so, it is not only useless but downright counter-productive for this branch to remain visible in the history graph, as an identifiable “railroad switch.” The real question you should ask yourself is this: “what does this other branch represent?” We want to move the current branch ahead so it incorporates the work of another branch. When should I use merge?Īs its name implies, merge performs a merge, a fusion. A top-notch history adds significant value to the whole team’s work, be it contributors coming in for the first time or getting back after a while away, project leads, code reviewers, etc. I shall try to not only highlight their respective roles, but also equip you with a few reflexes and best practices so you can always produce a public history that is both expressive (concise yet clear) and semantic (viewing the history graph reflects the team’s goals in an obvious way). ![]() They have entirely separate purposes and, indeed, are not supposed to be used for the same reasons at all. These two commands actually have hardly anything in common. I often see people put merge and rebase in the same basket, under the fallacy that both result in “getting commits from the branch across in our own branch” (which is, by the way, incorrect).
0 Comments
Leave a Reply. |