An interactive rebase is brilliant if you haven't pushed your work to a remote yet, because it allows you to slap together those twelve commits where you were testing out stuff and making typos that you removed later, and just keep the two or three where you made actual progress and logical additions to your code.
You even get to edit all your commit messages in one handy list!
This is a decent tutorial: blog.ona.io/general/2016/02/02/squ...
Except for the part where they do a --force push. Don't do that unless you're working alone, or you hate your colleagues.
But make sure to be careful enough when you use interactive rebase on a branch where you and your teammates work on at the same time. Because your force push may affect others code base.
Our convention is that if the branch has your initials in the name (e.g. 'rl-new-nifty-feature'), then it's yours, and you're the only one allowed to rebase it. Other branches must not be rebased.
Personally I like to commit often and also push to remote often to backup the work. I use personal working branch in the remote so I can safely rebase and force push without interfering with others. Once the feature is ready, commits tidied up and merged to master (meant rebased with master and integrated), the personal branch can be deleted.
I recommend to use git flow. Feature branches reintegrate into develop using rebase. Its better than the personal branch way, because you can easy switch between features and work on multiple features or keep them back for later.
Push as many times as you want to feature branches, but rewrite history on rebase into develop.
This is exactly how I'm doing it. Personal branch == feature branch, and there can be many of them. It seems that I wrote "merged to master" when in fact I'm using rebase. Wrong choice of words, I will edit it :) Thanks.
Learn to love $git rebase -i
An interactive rebase is brilliant if you haven't pushed your work to a remote yet, because it allows you to slap together those twelve commits where you were testing out stuff and making typos that you removed later, and just keep the two or three where you made actual progress and logical additions to your code.
You even get to edit all your commit messages in one handy list!
This is a decent tutorial: blog.ona.io/general/2016/02/02/squ...
Except for the part where they do a --force push. Don't do that unless you're working alone, or you hate your colleagues.
But make sure to be careful enough when you use interactive rebase on a branch where you and your teammates work on at the same time. Because your force push may affect others code base.
Our convention is that if the branch has your initials in the name (e.g. 'rl-new-nifty-feature'), then it's yours, and you're the only one allowed to rebase it. Other branches must not be rebased.
Personally I like to commit often and also push to remote often to backup the work. I use personal working branch in the remote so I can safely rebase and force push without interfering with others. Once the feature is ready, commits tidied up and merged to master (meant rebased with master and integrated), the personal branch can be deleted.
I recommend to use git flow. Feature branches reintegrate into develop using rebase. Its better than the personal branch way, because you can easy switch between features and work on multiple features or keep them back for later.
Push as many times as you want to feature branches, but rewrite history on rebase into develop.
This is exactly how I'm doing it. Personal branch == feature branch, and there can be many of them. It seems that I wrote "merged to master" when in fact I'm using rebase. Wrong choice of words, I will edit it :) Thanks.
Indeed!
I've even have an alias for interactive rebase:
git rbi
:)+1 for this.
git rebase -i HEAD~...