#Sublime merge interactive rebase update#

I like keeping the master branch clean and linear, and every commit message meaningful. After the pull/merge request is reviewed and accepted, squash the commits on the feature branch into one (manually, without merging) and write a meaningful commit message for it, linking the original issue ID.Create a feature branch for a small change.The workflow I use is based on rebasing and fast-forward, but it’s also very similar to the squash merge: None of them is a silver bullet, and you can make a mess out of both if you don’t use git properly. The final answer to “which one to use” is “it depends”.

Rebasing publicly impacts other people in the branch. Rebasing privately affects only the individual (prior to work being pushed). This is not the case when you create merge commits. At Perforce, we believe neither the always merge nor always rebase extreme is necessary.

If you have 79 commits, and there is a conflict, in the case of a rebase, you might be forced to resolve the conflicts 79 times (because the commits are added one by one to the tip of the master). Sublime Text style plugins are on our radar. We'll be adding extra commit wrangling functionality, including reordering commits, moving commits between branches, and amending arbitrary commits. Let’s assume you want to get the updates from the master branch and them to your feature branch. Sublime Merge currently supports editing commit messages and squashing commits (available from the commit context menu).

Perhaps a squash merge makes the most sense here.īut if you have one or two well-crafted commits, with meaningful messages, it makes better sense to add them to the master branch directly, instead of adding another “Merge branch feature_branch”. A real merge is also not a good option here: the merge commit points to the pile of junk. By doing a rebase and fast-forward, you’re adding a lot of junk to your master. But let’s assume you have a branch with 79 commits, each of which has a message similar to “big fix” or “update README”. We mentioned that merge commits are annoying. I do highly recommend the video above and it has one of my favorite quotes regarding rebase:Ī rebase creates a whole new line of history.This is not the case with rebasing, as it just puts your branch commits on top of the commits from the master. Sublime Merge is a graphical Git client from the creators of Sublime Text that. And the reason why you were able to recover the stash data starts around 1:23:37. An interactive rebase mode allows you to combine your commits into even a. I highly recommend watching the entire video, but if not the rebase section starts around 1:28:55. Here is what I skimmed and thought touched on all the right points to explain basics of git rebase -i:Īlso, one of the most useful (imho) videos & explanation of git in general is below. You must indicate how far back you want to rewrite commits by telling the command which. Given that one of Sublime Merge’s selling points is using ‘Real Git’ and the same terminology as Git, I think it would be rather wise to learn and experiment a bit with git rebase on the command line if you wanted to use the Edit Commit > options. You can run rebase interactively by adding the -i option to git rebase. I would recommend reading up on what rebase is and how it works. Select one or more lines to split hunks into multiple changes. Precise and Flexible Commit exactly what you want with line-by-line and hunk staging.

#Sublime merge interactive rebase update#

You can update master to also point to the new commit c by hard resetting master to commit c.īeware that by resetting you will lose the original unedited commit and any unsaved changes in the working directory (but given you've just updated the commit message that's okay).Įverything under the Edit Commit subdirectory is related to the git rebase functionality. A faster way to work With a zippy cross-platform GUI toolkit, an unmatched syntax highlighting engine, and a custom high-performance Git reading library, Sublime Merge sets the bar for performance. When you edit a commit, aBranch is recreated, starting from the edited commit.Ī new commit c is created, which duplicates First commit and updates the commit message.Īn additional commit d is created, which duplicates branch commit and sets its parent as the new commit c.ĪBranch is then updated to point at the new commits.Īs master is a completely different branch, it won't be updated. SourceTree does it superbly the local changes are shown in history. Master is pointing to First commit and aBranch is pointing to branch commit Fork cannot, nor can any other git client I have tried, including Tower and sublime merge. Your repository has two commits initially: First commit and branch commit This includes edits like commit messages, commit ordering, and commit contents. This is actually a byproduct of how Git works.Īll commits in Git are immutable - you cannot edit them in any way.Įditing in Git actually means you're creating a completely new commit, and updating the checked out branch (or HEAD) to point to the edited commit.