Therefore I have more contextual information on what change I did and what the correct version should look like considering the new base. I feel that resolving conflicts when rebasing is easier, as I do not have to solve all conflicts at once, and rather incrementally, in the way I developed my feature. Resolving conflicts is also part of merging, or bringing two states together and should not be a problem to you as the author of the software you are authoring. These conflicts have to be resolved properly, as git cannot decide which of the two versions of a line of code is the one that is supposed to be correct when applying your changes. Of course, when applying changes to another base, it is possible to run into conflicts. Force pushing a feature branch is completely fine, but please avoid doing so on your main or develop branches (of course, there are exceptions to that rule, in emergency cases) as members of your team have probably based their work on them.Īnother issue that is brought up is that “after the rebase, something broke”. If you have not pushed your branch to a remote yet, you will not even have to force push. If you are working on a feature branch with a team member, you should communicate first, but the moment your team member fetches, they will know about your forced push and can react accordingly. However, I feel that force pushing your feature branch should never be an issue. The repository browser was showing my repository in the 'Rebase' state. There was an easy fix for this issue via the command line however. It was stuck in the 'Rebase' state for one of my repositories and I had no way from within SourceTree to abort the rebase. To get the version on the remote to match yours, you will have to force push. 2 So recently I had a problem with SourceTree. If you have already pushed your branch to a remote, there will be a disparity between your local and the remote versions. When rebasing a branch, git takes the commits of that branch and applies them to the new base, resulting in a git history rewrite. I hope my explanation above rules both of these issues out for you at least, my dear reader (that makes us to rebase-buddies – welcome to the club of savvy rebasers!)Īddressing the second point, the fear of force push. Most of the time, people have issues with rebase because they either do not understand properly what it does, or they rebase the wrong way around (like the base onto the feature). Therefore, it is crucial to understand what we are doing, how our tools work, and to use them properly to achieve our goals. The same can be said about misconfiguring a service. you can mess up your code when doing it wrongĪddressing the first argument, yes, obviously, your result will not be what you expected it to be when handling the tool you are using in the wrong way.The more significant arguments against rebase are: If you are looking into rebasing, you might find opposing opinions on its use.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |