nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Understand git rebase interactive

jmejiaa1986

I'm using sourcetree with git and I am doing the following.

Creating a local branch from master called defect123. After making 10 commits to defect123 branch, I want to merge it into master but with only one commit with message "Fix for defect123"

Is this possible?

Accepted answers

All comments

Seth

Yes. You can do this by NOT rebasing, and just merging.

jmejiaa1986

Can you explain? I've done merging a lot in the past and have never seen a way to do this.

Seth

Sure. How do you do your merges? Do you right click defect123 and select "Merge defect123 into current branch", or do you use the Merge button at the top of the window?

jmejiaa1986

Actually, I don't think I've done right clik and commit, when I do this it asks if I'm sure and I get the impression it will only merge that one commit and not all the work on my new branch.

crf

git fetch origin
git rebase -i origin/master

When the editor appears, change the first commit to "r" and all of the others to "s" then save and quit. When the editor reappears, change the commit message to a summary of what the whole thing is.

If all goes well, you will have a rebased single commit for the whole work. You will have to force push it either explicitly or by deleting and recreating the branch:

git push -f origin mybranch # or....

git push origin :mybranch
git push origin mybranch

Disclaimer: This rewriting of history will be frowned upon by many people. Whether or not it is okay to do this depends quite a bit on what your workflow is and who else might be looking at your branch. If anyone else is sharing your feature branch, then force pushing the single commit up is likely to cause chaos. In larger projects, the nice pretty clean history simply isn't worth the potential disruption and it is safer to do a simple merge. Another objection is that rewriting the history is somewhat dishonest, as it lies about the code base that you wrote your changes against, which can make it harder to sort out what went wrong later if somebody had introduced an incompatible change on the master. This is advanced stuff -- treat it with kid gloves.

crf

Note: to actually get it onto master, you can either merge it or cherry-pick it over. This too is a controversial decision. Most people would prefer that you merge it, but again -- this depends a lot on your workflow and who else you might be working with.

jmejiaa1986

Thanks to all, I actually decided to just merge, I feel my commits may be more useful to me in the future than one big commit anyway..

Thanks.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

sourcetree

git