CODEWITHSUNDEEP
gitatlassian-sourcetreegit-flow
effemmeffe
effemmeffe

Reputation: 133

New to git, why I see my changes on develop branch even if I stage them on feature branch?

I'm new to git.

I'm following the git-flow branching model so I have the branches master and develop and every time I need a new feature I open a new feature branch.

I did some changes to a couple of files in the feature branch and I staged them, not committed yet since the changes are not tested yet:

$ git status
On branch feature/ParamConfigFaultCollection
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   IOLSE_User_Objs.h
        modified:   data.c

Now I need to work on the branch develop, so I switch to it, I use Sourcetree as git GUI and I double click on develop: enter image description here

and I was expecting that the changes in the stashed files on feature branch would not be visible to develop, but it seems that the changes are present in develop too:

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   IOLSE_User_Objs.h
        modified:   data.c

What am I doing wrong?

Upvotes: 2

Views: 398

Answers (1)

jessehouwing
jessehouwing

Reputation: 114822

The changes that you have Staged aren't stashed. They are prepared for the commit. When switching between branches any uncommitted or not-stashed changes will stay in your working area and when Git can perform the switch to another branch without overwriting your changed files, it will allow you to do so.

If you don't want to take your changes with you, you will have to either:

  • best option: commit them to your feature branch first to clean your work area
  • not a bad alternative, but as some drawbacks: stash them and clean your work area
  • worst case: create a new temporary branch, commit your changes there and cherry-pick them back later.

Then switch to the other branch.

Some clients will offer you to do the stash on your behalf. I prefer not to do that, since it's easy to forget about the stashed changes when I switch back.

What I'd do instead of stashing, is to commit my changes on the feature branch, preferably with a very clear commit message explaining these aren't ready yet, then, when I come back to that branch I can either:

  • Amend the commit to add additional changes to it prior to pushing them
  • Do an interactive rebase of the changes together with additional changes to clean up the local history prior to pushing
  • Do a git reset --soft HEAD~1 to undo the temporary commit, but keep it's changes, then work some more on it and commit them again later in a new commit.

As long as you don't push your changes to the remote server, you can tweak your local history until it looks the way you want it.

Upvotes: 7

Related Questions