Menu
git rebase -i origin/master shows the editor with a single "noop" entry. Confirming that would make a fast-forward merge to origin/master. Git Rebase Dialog in IDEA, on the other hand, shows an empty rebase editor with no entries inside, confirming it makes rebase do nothing.
You can run rebase interactively by adding the -i option to git rebase . You must indicate how far back you want to rewrite commits by telling the command which commit to rebase onto. Remember again that this is a rebasing command — every commit in the range HEAD~3..
Squash commits together. Two other commands rebase interactive offers us are: squash ( s for short), which melds the commit into the previous one (the one in the line before) fixup ( f for short), which acts like “squash”, but discards this commit's message.
The purpose of rebase is make your commits look as if they were changes to the branch you rebase onto. So the most logical way is to incorporate merge conflicts into these commits. No additional commits is required thus.
Like a non-interactive rebase, you have to rebase onto a particular commit.
With a non-interactive rebase, if you supply a direct ancestor of the current commit then you aren't changing anything; with an interactive rebase you can edit commits after the commit that you are rebasing onto, even if the commit is a direct ancestor of your current commit but you do have to specify this commit that you want to edit onwards from.
I don't know the details of your situation but you might want something like this:
# Opportunity to edit or prune commits between origin/master and current branch
git rebase -i origin/master
or
# Edit some of the last ten commits
git rebase -i HEAD~10 # Note that ~10 uses a tilde("~") not a dash("-"_) !
rebase -i without a commit range will not display any commits. to rebase the last, say, 7 commits use the following:
git rebase -i HEAD~7
be careful though, that this will rewrite history. don't do it, if the commits are already pushed
for your second question: have a branch with your changes (basically a configuration branch) and regularly merge the other branches into it. this way the changes will not move to other branches
When you're using git rebase -i, you usually have to specify from which commit do you want to perform the rebase. So, if, for example, you want to remove some of the commits among the last 10 to the current branch, you would do:
git rebase -i HEAD~10
As others have mentioned, you need to specify a commit range.
git rebase -i <latest-commit-to-be-retained>
(Assuming that you are on the same branch as the commit to be edited)--
To specify the commits, you can use the HEAD~5 shorthands or use sha checksum (which you can get by git log)
In fact any commit will do if it is prior/ancestor to the commits which you want to delete/edit/reword in the tree. This will list all the commits since the <latest-commit-to-be-retained> in the editor(defined in your git config). From the list, to delete a commit, just delete that particular line, save and exit (vi habbits :) )the file+editor, and do git rebase --continue
For the second answer, I agree with knittl
have a branch with your changes (basically a configuration branch) and regularly merge the other branches into it. this way the changes will not move to other branches
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With