![]() ![]() ![]() This starts an interactive rebase as before. The first command is git rebase origin/master -i In 30 seconds, a moderately sized branch can be updated to ensure all the commit dates match their position in the branch. For each commit, edit the commit date to be the current time.Instead, I opted for a slightly more manual approach. That made things even worse in the pull request - now the commits were ordered completely randomly! The commits all ended up having the same date. The main problem I had was that these were too fast. I looked for a few automated ways of doing this using git filter-branch and similar that I won't show here. The only solution I could come up with was to rewrite the commit dates to be in the same order as the commits. The solution: changing the dates on commits GitHub uses the author date to control ordering, which is not changed when you reorder commits using rebasing.Īfter spending a while rebasing a branch recently, only to have GitHub randomly scatter the commits in the PR, I went looking for a solution. It's worth mentioning that there are actually two dates associated with each commit: the author date, and the committer date. 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 |