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.

  • Rename branch on github website?
  • How do I create a new branch based on an existing Git hub branch? (Please read - tried the beginners guide)
  • Versioning on development and release branches (git-flow)
  • Why are deleted branches not removed on the remote after pushing?
  • Code review of a branch in GitHub
  • Git: about to fork my own project
  • 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!

  • git init --bare on git 1.5.4.3
  • How do you revert to a specific tag in Git?
  • Undo a merge that has been pushed
  • automatically rejecting a commit based on certain criteria
  • How does Xcode work with Git for changing branch and checkout older commit?
  • Error: Cannot pull with rebase: You have unstaged changes
  • 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.