Git – Best practice: How to switch very often between branches and avoid multiples commits?
I am working on a validation software.
I keep on the master branch code that is always ready to launch tests.
So I develop the new features in other branches (dev for ex).
This is classic git workflow.
My concern is that it happens that I need to switch betwen master and dev 10 times a day because the designers ask me to check their updates.
At the moment I only know one way:
- Commit my work on dev with message “Regression required”
- Switch to master branch
- Run regression and give feedbacks
- Switch back on dev and keep on working
This is annoying because of the useless history created on dev branch.
Is there another simple way (I am a beginner) to avoid the multiple commits on dev branch?
Thank you for your help!
4 Solutions collect form web for “Git – Best practice: How to switch very often between branches and avoid multiples commits?”
Before switching branches, do
git stash. This will record the current state of what you’re working on in a way that is easy to recover. When you switch back to your dev branch, do
git stash pop. This will re-apply those changes, and delete the stash so that it doesn’t stay around in your history.
I think that
git stash is what you need. There’s help on it here.
git clone your master repository, and run the regression tests from there.
Remember to run
git pull to retrieve updates. And never commit to the cloned repository (or be prepared to merge that back to the master repository asap).
Several good suggestions here. My first thought is to have two clones, on on dev and one on master. Just change directories (similar to what ydroneaud is saying).
Another way, if you just want to run regression, is to use git archive to fetch a snapshot and test with that. Go to an empty directory and do:
git --git-dir=/my/dev/clone/.git archive master | tar xvf -
then build & test. Of course it makes sense to put this in a script.