![]() perform multiple commits remove specific changes, etc. This will un-commit the latest commit, but leave its changes in the working directory, so you can then do what you want with them - eg. So after the interactive rebase stops, the first thing you'll usually want to do is reset that commit with this command: git reset HEAD^ One caveat is that when it stops, the commit you're editing has already been committed. If you choose to edit a commit (by changing 'pick' to 'edit'), then the rebase will stop when you get to this commit. Save and close this file, and the rebase will continue. changing a commit message - then your default editor will be reopened asking you for the new commit message. If you've requested any changes that require further input - eg. Git will detect that the file has been closed, and will begin the rebase. Once happy, close the file, saving the changes. If you're editing a commit message, then don't try to edit the commit message in this file - you'll be prompted for the new commit message shortly. Just remember that the list of commits is ascending, not descending - so if for example, you wanted to combine two commits using the squash command, you would replace the 'pick' in the line of the second commit with 'squash' (or just 's' for short). The reference in the comments at the bottom of the file do a pretty good job of summarising what each command does, so I won't echo what's already said there. The default value of 'pick' which you see in the example above just means to use that commit - hence why if you don't edit this file, it'll do a normal replay of original commits. To modify what the rebase will do, all you do is edit the word at the start of each line. If you close this without making any changes, then it'll do the same as a non-interactive rebase and just replay them as is. These are the commits that are about to be replayed (displayed in ascending order). It's the lines at the top which are important. The lines starting with a hash symbol (or 'pound' symbol depending on where you live!) are just comments to help you out. # Note that empty commits are commented out # However, if you remove everything, the rebase will be aborted. # If you remove a line here THAT COMMIT WILL BE LOST. # These lines can be re-ordered they are executed from top to bottom. # x, exec = run command (the rest of the line) using shell # f, fixup = like "squash", but discard this commit's log message ![]() # s, squash = use commit, but meld into previous commit # e, edit = use commit, but stop for amending # r, reword = use commit, but edit the commit message When you start an interactive rebase, your default text editor will pop up with a list of the commits it's going to replay. In most scenarios where I'm doing an interactive rebase, I tend to always do this. starting the replaying of commits from the 'origin/master' commit. However that could have been any of Git's many ways of referencing a commit - a branch reference, a commit id (SHA), etc.īy choosing 'origin/master', it will replay all the local unpushed commits in the master branch - ie. So from the command line, you could do this: git rebase -i origin/master The golden rule still applies in that you should only modify the history of commits that haven't been pushed, as this can cause bad headaches for other developers! How do you do it?Īn interactive rebase is started with the -i flag. Split out the commit into multiple commits.Here are some examples of what you can do. Interactive rebasing gives you much more power by giving you a list of commits that are about to be replayed, and asking you want you want to do with those commits. However, there are other changes you may need to do to tidy up your local commits before pushing. I only covered a very basic rebase to tidy up the local commits before pushing them and get rid of the merge commit. So what is an interactive rebase?Īs mentioned in my last post, a rebase is where Git replays commits to change the Git history in some way or another. However, it does fit nicely into a follow up post about more advanced Git rebasing!. As that would have then moved into the topic of interactive rebasing, I felt that this was beyond the scope of the particular problem I was trying to discuss. After getting feedback from a colleague, it was suggested about also mentioning squashing commits as another way of tidying up the commit history. That post only talked about a very simple rebase to avoid that particular problem. It makes the history extremely hard to read and understand. the branches are diverging and remerging back in all the time. The problem is that it creates pointless merge commits, and also stops the Git history from being linear, ie. My last post was focused around a problem in Git which occurs when the rebase command isn't used, and developers blindly use pull/push.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |