That's what GitHub uses, and is the root of the problem. If you think back to the image of our branch prior to pushing, you'll remember the dates on the commits didn't change when we rebased. The problem is that GitHub orders the commits shown in the pull request by the author date, not by their logical position in the branch. "If you always want to see commits in order, we recommend not using git rebase."Īs someone who uses rebasing as a standard part of their workflow, that's not very helpful. Unfortunately, their solution isn't entirely useful: This is a known issue in GitHub, with a page dedicated to it on their help pages. Not that GitHub displays commit in ascending order of date, whereas the gitk tool I used in the first two screenshot display commits in descending order of the branch. That's not very helpful, given that we specifically reordered the commits in the branch to make more sense to reviewers who are reviewing commits in sequence. The image above shows the original commit order of 1, 2, 3 instead of the revised order of 3, 1, 2. The problem is that the order of commits shown in the Pull Request do not reflect the actual order of the commits in the branch: I wrote about hub in a previous post.Įverything probably looks OK initially, but if you look a little closer, there's something not quite right… The problem: GitHub doesn't preserve commit order I like to create pull request from the command line using the hub command line tool. You push the branch to GitHub, and create a pull request for viewing by your colleagues. With the branch all cleaned up, it's time to push your work to the server. Now it will look the following:Īn important point here is that while rearranging the commits changes the git history, the date associated with the commit doesn't change (on the right hand side of the image above). Pick f3b9e40 commit 3 # Rebase 82df143.d605e5a onto 82df143 (3 commands)īy rearranging the commits in the file, git will rearrange the commits in the test branch. This pops up an editor listing the current commits on the branch, and lets you rearrange, edit or squash them for example pick 68f39b8 commit 1 You can easily rearrange commits using interactive rebase by running git rebase origin/master -i Of course, if you squash everything into a single commit, then this whole post is moot! The example here of rearranging commits is just the simplest case. into something that makes a logical story. Likely you would do extra work here, like squashing some commits, splitting others etc. Looking at your commits, you decide that it makes sense for "Commit 3" to be the first one on the branch, coming before the others. "Commit 3" is the *drum roll* third commitĪt this point you've just about finished the feature, but to make things easier for your colleagues, you decide to clean-up your local branch before creating a Pull Request.In the image below, we have a branch called test based off the master branch that has 3 commits: Let's imagine you're working on a feature in a branch, and you've made several commits. You should only ever do that to a branch if you're sure other users aren't basing their own work on it! The setup: cleaning up a local branch using rebasing Warning: this post uses rebasing to rewrite the history of a Git branch. the logical order of the commits to a branch, not the date order. In this post I show how to ensure your commits in a GitHub pull request (PR) are in the order you expect for reviewers - i.e.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |