AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Git rebase remote1/21/2024 ![]() ![]() Imagine that the yellow dots are main and the purple ones are your branch/PR. On the left you see a merge, in the middle is your typically branching and on the right you can see a rebase. Have a look at the graphic below which will hopefully make it a bit more clear. After each commit is replayed there is a check if there are conflicts which you should then fix, but more on that later. Then commit by commit your changes are re-added on top of the latest state on main. When you do a Git rebase you take that latest state of the main branch. Since you opened the PR, new commits were added to the main branch. Imagine you want to add commits to the main branch. What will happen during a Git rebase is that the commits you want to add to the codebase are replayed on top of the target branch. This is where things start to get a bit scary, because it involves rewriting history due to force pushing. As you can see, there are a lot of reasons for a rebase. Or your code hooks into new code that is now added in the target branch. Another reason might be that you have just opened the PR at a time where the tests or build were in a bad state. On the Xamarin.Forms repository we might ask you to do a rebase whenever there are conflicts. That will however give a lot of merge commits and isn’t very clean. What you could do is merge the changes from the target branch into your PR branch. These are conflicts between your code changes in the PR and other changes that got merged into the target branch. Meanwhile, development goes on and the branch you are targeting with your PR gets updated. Unfortunately reality is that your PR might be sitting there for a while. You have gathered the courage to open that PR and hope it will get merged soon. ![]() The Backstory #įinally, your change is ready for the world to see. So where it says master in the screenshots, you can substitute that for main. Git push -f origin master You only need to use the -f the first time after you've rebased.Note! In the screenshots the branch is named master I have updated the text to now use main. ![]() If you've rebased your branch onto upstream/master you may need to force the push in order to push it to your own forked repository on GitHub. However, for making further pull requests that are as clean as possible, it's probably better to rebase. ![]() Git rebase upstream/master If you don't want to rewrite the history of your master branch, (for example because other people may have cloned it) then you should replace the last command with git merge upstream/master. Git checkout master Rewrite your master branch so that any commits of yours that aren't already in upstream/master are replayed on top of that other branch: Git fetch upstream Make sure that you're on your master branch: Git remote add upstream Fetch all the branches of that remote into remote-tracking branches, such as upstream/master: In terms of commands that might look like: Add the remote, call it "upstream": ("Remotes" are like nicknames for the URLs of repositories - origin is one, for example.) Then you can fetch all the branches from that upstream repository, and rebase your work to continue working on the upstream version. In your local clone of your forked repository, you can add the original GitHub repository as a "remote". ![]()
0 Comments
Read More
Leave a Reply. |