![]() When you do an interactive rebase, git prompts you with a file like the one below to determine what actions you want it to take. This extension is a bit of a niche extension, but I really like it! The inspiration for this post was the fabuluous Git Rebase Shortcuts extension for Visual Studio Code. I realise that this post is starting to get a little long for a mini-post, and I’ve not yet mentioned VS code (which is in the title!). If you take a copy of the top project folder ( your-project in the example above) then you have a full backup of the state of your code and commit history! It may sound a little extreme, but it definitely helped give me confidence to perform a rebase on a couple of occasions :-) One final point on the safety net theme: your code and git state are all in your source folder. ![]() Then if you aren’t happy with how the rebase went you can just git checkout starting-point to get back to the commit you were originally on. Not being deleted doesn’t mean that they are easy to access you could make a note of the commit ID, or you could just git branch starting-point (or some such) before the rebase and give yourself a nice easy name to refer to the original commit by. ![]() I’ve also had a few occasions where aborting gave me an opportunity to squash together some related commits and remove some of the rebase conflicts in the process.Īlso, since rebase creates new commits your old commits aren’t deleted as part of the rebase and can still be accessed after completing the rebase if you want to go back. Aborting can be useful to just go back and remind yourself of the original changes so that it is easier to understand how to resolve conflicts during a rebase. Secondly, when you are in the middle of a rebase you can do git rebase -abort and git will wind everything back to where you started. But, it has a bunch of different scenarios laid out as commit graphs with the before and after states along with the commands to execute. That’s not to say that it won’t need a few readings - git rebase is a powerful tool, after all. works offline) and is actually really good. By way of encouragement, I’ll add that getting familiar with git rebase is a huge part of the reason that I love git and has improved my developer workflow.įirst up, git rebase -help is your friend. So this post has a few tips that I wish I’d known at that point. ![]() Now, I’d heard of rebase at that point but I hadn’t used it, so I was a bit daunted. Eventually, I was working on a pull request for an OSS project and a maintainer asked me to rebase my changes. When I first started working with git I found a way to pretend that it was a source control system like any other that I’d used. Following the git theme for mini-posts, I thought I’d give git rebase a mention this time. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |