August 11, 2019 • 2 min read
I know there’s a better way to do this (using rebase) but I like this way since it gives me more control.
git merge-base master yourBranch # note commit hash git reset --soft # enter commit hash # all changes can now be committed again
It’s easier on *nix using the following oneliner:
git reset $(git merge-base master $(git rev-parse --abbrev-ref HEAD))
Rebase using the remote master to make sure you’re really up to date. Useful when updating merge requests (on GitLab).
git pull --rebase origin master
git checkout master -- yarn.lock
ac=!git add . && git commit
ls = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
amen = !git add --all && git commit --amend
git reset --soft HEAD^
Or add as an alias:
git config --global alias.undo 'reset --soft HEAD^'
Use the following command:
cherry-pick any commits you think could still have all your work.
git rm -r --cached .
And after that:
git add --all
MacOS by default ignores case in filenames and directories. Those differences go unnoticed until you push your working code to CI, where the build fails. To fix this once and for all use:
git config --global core.ignorecase false
Instead of using -f or —force developers should use
git push --force-with-lease
Why? Because it checks the remote branch for changes which is absolutely a good idea. Let’s imagine that James and Lisa are working on the same feature branch and Lisa has pushed a commit. James now rebases his local branch and is rejected when trying to push. Of course James thinks this is due to rebase and uses —force and would rewrite all Lisa’s changes. If James had used —force-with-lease he would have received a warning that there are commits done by someone else. I don’t see why anyone would use —force instead of —force-with-lease when pushing after a rebase.