It is good to have meaningful commits merged to master branch but when you actually commit, usually they are not so.
So we do rebase and most time we use rebase squash.
But you know, there’s easier way to squash commits with reset.
Reset: easier than rebase squash
we use reset to remove working-tree or change HEAD(which indicates the last commit of the branch) of the branch.
reset has 2 options.hard and soft.
hard removes all the working tree and the staging(except untracked files), but soft preserve changes as working tree.
With this definition we don’t need to process every steps of rebase(remember, this is only for squash..) to make squashed commit.
We’re gonna use git reset (soft is default so no need to add option)
Here’s how you do it.
- Check the base commit Id(<BaseCommitId>)
- Do you job(make commits as you want)
- git reset <BaseCommitId>
- Now your branch has BaseCommitId as HEAD and the work you did over several commits are on working tree
- git add. | git commit -m “This is new Commit.”
It is easier also easy on resolving conflicts situation which I experience awful moments with rebase.
- master HEAD commit id as <v1>
- You make a feature branch from <v1>.
- Do you job(make commits as you want- a1, a2, a3… an)
- There were another commit to master you did not expect. we call it <v2>
- merge <v2> to your feature branch and resolve conflicts
- git reset <v2>
- git add. | git commit -m “This is new Commit.”
This makes commit based with the v2, no merging commit would be created.
// current commit(L1)
// merge any branch(here we say it is master)git fetch -p (to store commit log on local from remote)
git pull origin master(R1)// resolve conflict
// current commit L2git reset R1
git add .
git commit -m "there's no diff with L2"
I hope this small tip helps you manage commits meaningful. 🥰
