Multiple features for one branch – what's the point?

On SourceTree, I have one branch called “develop”. I use SourceTree Git Flow to create a new feature from the “develop” branch. I make changes to the feature branch and then finish the feature and the changes go back to my “develop” branch.

I then push these changes to the remote.

Now, here’s what I was trying to do. I had to work on two JIRA tasks at the same time. So I created two feature branches from the “develop” branch: “develop/feature1” and “develop/feature2”. I can switch between the features by double clicking them when selected on SourceTree. I can then check the working copy for both feature branches, but I noticed that files I added to one have also been added to the other.

My questions are:

  1. When I add files to one feature’s working copy why do they appear in another feature’s working copy?

  2. What is the point of having feature branches if they can’t isolate changes from each other?

  • Git flow - create feature branch off another feature branch
  • How to checkout gitflow branches?
  • With Git feature branch workflow, when do you update the master branch?
  • git subtree merged on root of repository (w. git-flow)
  • Bash and Git Flow bug in common file
  • Storing incomplete work with git flow
  • Why are deleted branches not removed on the remote after pushing?
  • git flow branching model branching
  • 2 Solutions collect form web for “Multiple features for one branch – what's the point?”

    git allows you to switch branches even if you have uncommitted changes in your current branch. The files remain uncommitted and you can commit them in the other branch if you need to. This is great when you realize that you’ve done work on feature/feature1 that should be on feature/feature2.

    Once you have committed the changes, they do not switch between branches any more. You then could merge or cherry pick changes between branches.

    Note that git will not allow you to switch branches if you have uncommitted changes that cause merge conflicts in the branch you want to switch to, and maybe even if one of your changes is in a file that has been changed and committed in the branch you want to switch to. In that case you need to commit, revert or stash your changes first.

    If git does not allow you to switch branches and you try to resolve that by stashing your changes before switching branches, you should make sure that you stash pop in the original branch. If you are on feature/feature1, stash changes, then switch to feature/feature2 and stash pop there, you will loose changes that were present in feature/feature2 but not in feature/feature1. This is hard to detect.

    New files and changes are not tracked by git until you do a git add. That means that git does not have a copy of this data, so if it were to revert your changes when you check out a different branch, it wouldn’t be able to restore them afterwards.

    You can see lists of which files are indexed, modified, and untracked with git status.

    The only way to solve this problem is by tracking your changes with git, either by adding and committing them (which you can undo later with a git reset), or by stashing them with git stash -u1 (which can be undone later with a git stash pop).

    The advantage to git working this way is that you can work on anything you want without having to think about branches. When it comes time to commit, you can simply checkout the relevant branch and add the files you want with git add, or add only the parts of the files you want with git add -p.

    1: -u is shorthand for --include-untracked, which includes newly-created files but not ignored files

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