If you reorder commits you will change commit hashes rebasing (when it does something) will change commit hashes. Huge thanks have to go to Mattias (a.k.a devlead) for showing me that this was possible.Each commit hash in Git is based on a number of factors, one of which is the hash of the commit that comes before it. Someone has went out of their way to make a contribution into your project, so make sure that you say thank you! One of the most important things in Open Source is to be kind and courteous. Now, all you have to do is wait for these builds to finish, and assuming everything went well, you will see the following:Īt which point, you can merge the PR. all the CI builds for this PR are triggered again, but this time, the branch is up to date with the base branch. These are the steps that I follow: mkdir jnm2ĭoing this last step causes the following to happen: Then, once all the CI builds pass, we can get the PR merged in. So, let's go ahead and rebase the PR branch with the latest from upstream, and push the changes back. This tells the maintainer of the project that when this PR was created, the box was checked to allow changes from the maintainer. If you look closely at the above screen shot, you will see the following text:Īdd more commits by pushing to the wixheat-pog-fix branch on jnm2/cake Having reviewed the changes in this PR, I can say that it is good to go, however, this is the current state:Īll the CI builds associated with the PR have passed, but it is now out of date with the base branch, meaning that it needs to be rebased. Let's see this in actionĪs an example of where this can be used, let's use this PR. I would encourage any contributor to leave this checkbox ticked when submitting a PR, as it does open up much more flexibility on the part of the maintainers of the project. Doing anything else would leave their branch in a state that differs from their local copy of the truth, and quite simply, it would be bad form to leave it in this state, so don't do it! The contributor has to allow the branch to be updatedĪs mentioned in the linked article, allow a PR branch to be updated is something that the contributor can choose not to allow, but it is enabled by default: NOTE: Performing a rebase on someone else's fork is really only something that should be done if you intend to merge the PR straight away, once any CI builds have passed. Being able to do this on behalf of the contributor opens up the potentially for a much quicker turn around on merging a PR. But again, rebasing can be quite daunting. Thankfully I had a lot of guidance from rismoney to help with this. I remember the first time that I was asked to do this on a PR into the Chocolatey Repository, and I literally had NO clue what I was doing. However, asking a contributor to an open source project to rebase a branch can sometimes be quite daunting. On the projects that I work on, when this happens, there is a preference to have the changes in the PR branch rebased with the upstream branch, therefore bringing it up to date. Secondly, the very nature of Open Source contributions means that there might be some time between when the PR was submitted, and when it is reviewed and ultimately merged. It is sometimes quicker to simply make the change, rather than trying to explain it.Any Continuous Integration checks performed on the PR can be run again with these changes in place.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |