![]() ![]() Therefore, if we would rewrite the history in remote master, it would cause all of its local copies not to match. Rebasing overwrites history, and we need to acknowledge that everybody on our team uses the master branch. While this is fine, doing it the other way would cause trouble. ![]() Then, we’ve merged the feature - two branch back to master using a fast forward merge. Above, we rebased master into our feature - two branch. The most important thing about rebasing is not to do it on public branches. By sticking to rebasing, we end up with a linear project history that we can easily follow from the tip down to the bottom. Let’s look into the git log now:Ĭommit 6c943d260b6aa0fabfe77899babb8bb67ebb1e95 (HEAD -> master, origin/feature-two, feature-two)Ĭommit 318ff57e470d10dfe5924da38455b85dac667898 (origin/master)Īs you can see, there is no merge commit whatsoever. The crucial thing above is the fact that we’ve performed a fast-forward merge. If we would like to push the rebased version of our feature - two branch to our remote repository, we might encounter some issues. There is one important thing to cover here. We can see that the hash of our new commit changed.Ĭommit 536676c27b51922b6e65568cebc1b7a9932704e0Ĭommit 6c943d260b6aa0fabfe77899babb8bb67ebb1e95Įven though the above commits bring the same set of changes, they are different from the Git point of view. To see it better, take a closer look at the above logs. The important thing is that when we rebased, Git created brand new commits when applying our changes on top of the commits from the master branch. ![]() When doing that, we moved all of the changes from master to the feature - two branch and applied our changes on top of it. With rebasing, we re-wrote the history of the feature - two branch. To visualize it, let’s start with a clean repository:įirst, rewinding head to replay your work on top of it…Ĭommit 6c943d260b6aa0fabfe77899babb8bb67ebb1e95 (HEAD -> feature-two)Ĭommit 318ff57e470d10dfe5924da38455b85dac667898 (origin/master, master)Ĭommit b828ed40f9edd2aa56d99d4d351c624d7c6fbcef Rebase aims to rewrite git history so that it is simple and straightforward. This might not be the desired outcome if we aim for the readability of our git logs. In the previous part of this series, we’ve learned that merging can result in an additional merge commit. In this article, we look into rebasing and learn how we can use it as an alternative to merging. Merging is not the only utility that can integrate changes from one branch onto another. Keeping our Git history clean with fixup commits Improving our debugging flow with Bisect and Worktree This entry is part 5 of 11 in the Getting geeky with Git ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |