Difficult to see which commits relate to which PR / branch. Can cause frustration as, if someone was to commit to the base branch against before you get to merge, you have to rebase again.Keeps the individual commit granularity.This is like a fast forward merge, but works when changes have been made into the base branch in the mean while Lost of granularity, any useful detail in those commits that made up the branch is lost, as are any interesting decisions, changes in logic etc captured during the development process.Ī rebase and merge will take where the branch was created and move that point to the last commit into the base branch, then reapply the commits on top of those changes.Can look at a single commit to see a full piece of work, rather than shifting through multiple commits in the log.That commit is then added to the history, but none of the commits that made up the branch are preserved Squash takes all the commits in the branch (A,B,C) and melds them into 1 commit. Can be seen as a inaccurate view of history as it hasn’t captured that a branch was created, or when it was merged.Can only be done when the base branch hasn’t had any new commits, a rarity in a shared repository.The idea is because no changes were made to the base branch there’s no need to capture a branch had occurred. This is as if you made the commits directly on the base branch. This is the same as a Merge but does not create a merge commit. If we change our example so no new commits were made to the base branch since our branch was created, Git can do something called a “Fast Forward Merge”. Can end up having a complex graph of previous branches that’s more difficult to read.Can be especially confusing if you are trying to revert a set of changes. Merge commits are often seen as messy as they are empty and only really there for historical reasons.Allows us to see each commit that made up the eventual merged changes, no loss of granularity.
0 Comments
Leave a Reply. |