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.

  • How to bring the git remote branch references local
  • TFS Branching & Merging Strategies
  • Dynamically Fill Jenkins Choice Parameter With Git Branches In a Specified Repo
  • What's the ideal git branching strategy for this product development?
  • Where should I upload the built file of a github branch?
  • Delete a github branch
  • At the moment I only know one way:

    1. Commit my work on dev with message “Regression required”
    2. Switch to master branch
    3. Run regression and give feedbacks
    4. 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!

  • How to revert a file in Git that has been renamed
  • How can I upload committed changes to my GitHub repository?
  • How to use SSH keys with Jenkins Workflow Plugin
  • How to recover from “unordered stage entries in index” error in git
  • GIT select private key to use
  • In git how do you point the MASTER pointer(branch) to another commit without merging?
  • 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.

    Git Baby is a git and github fan, let's start git clone.