![]() And you should at least compile test the new commits. But whenever you do use it, you need to be aware of the fact that you are lying about history. I am not saying that you shouldn't use git rebase. The consequence of this may be, that you can't distinguish which of the three commits E, F, and G actually introduced a regression, diminishing the value of git bisect. It is actually quite easy to create nonsensical commits via a rebase, especially when the changes in master are important to the development in b1. The point is, that the commits E', F', and G' never truly existed, and have likely never been tested. The rebase, however, gives you this history: A - B - C - D <- master The merge results in the true history: A - B - C - D <- master If the remote branch cannot be fast-forwarded, the push will be refused. Pushing attempts to upload any new commits to the remote branch, then fast-forward the remote to bring it up to date with the local repo. Consider this commit graph: A - B - C - D <- master Push the currently checked out branch by clicking Push in the main toolbar, or by right clicking on the branch, and selecting Push. However, this linear history is a lie, and you should be aware that it is. People like this approach because it retains a linear history in all branches. The commands are analogue to the merge case: git checkout b1 People with an SVN, or similar background find this more intuitive. The only difference is, which branch ends up pointing to this merge commit. It simply does not care whether branch b1 merges master, or master merges b1, the merge commit looks all the same to git. ![]() Instead of opening the regular diff view you’re familiar with, it will open a specialized view for helping you resolve merge conflicts without having to leave the app. You can trust it be able to get all threads together correctly. When you have a merge conflict, simply click on the conflicted file. Git can handle this situation really well, it is designed for merges happening in all directions, at the same time. This leaves the history exactly as it happened: You forked from master, you made changes to all branches, and finally you incorporated the changes from master into all three branches. That is actually quite simple, and a perfectly local operation: git checkout b1 ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |