The reason for this is that when you rebase stuff, you are actually abandoning existing commits and creating new ones that are similar, but different. Git documentation mentions that if you don’t follow this rule, “people will hate you, and you’ll be scorned by friends and family”, haha. Do not rebase commits that exist outside your repository and that people may have based work on It appears that all the work happened in series, one after another, even when it originally happened in parallel.īecause of this advantage, you will generally use rebase to update your branch with the master branch while contributing to public open source repositories, so that there won’t be any unnecessary extra merge commit. If you examine the log of a rebased branch, it looks like a linear history. But, if you want to preserve the record of what actually happened, you’ll want to go for merge. If you want a clean linear history which can show how you went from point A to B, you’ll use rebase to keep the history clean. You will choose between rebase and merge depending on your preference for wanting history. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together. You might have noticed that the snapshot pointed to by the final commit you end up with, whether it’s by using rebase or by using merge is the same. To summarise, doing git rebase master while on mybranch will take all the new changes that were committed in master and will “reapply” it on mybranch, so that mybranch will now be based on the latest version of masterĪ rather simple rule of thumb would be ” merge to master branch, and rebase the feature branches”.So now, the feature branch is no longer “based” on the the old master (C2), but now is based on the new master (with C3 included).Then, you do your work on the hotfix branch, make a new commit C4, and now you merge it to master, so you checkout master and merge the hotfix branch.Lets say you are on master with latest commit C2, and you want to make some changes.When you do git merge, there are two possibilities based on how your history is. Turns out, there are two ways to integrate changes from one branch to another in Git. So, now at this point, I will have to update that branch with changes from master. The fix for failing tests was merged to master, but that fix isn’t there in my branch (which I checked out before the fix was merged), so my tests still failed! Now, back to our original PR of adding new tests. I created a new PR which would fix the failing tests on master. Then, I looked into what was causing the tests to fail on master, and with some help, was able to fix it. But, there was an existing issue from master which caused tests to fail. So, when I checked out a new branch, that code came in my new branch as well, and I was working on a adding unit tests, so it was essential that all tests pass for my PR. When I checked out a new branch to work on, there was an issue in the master branch which caused the tests to fail on the CI. Background context on how I ended up needing to do a rebase or merge.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |