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.
- Feature Branch Workflow Tool
- Avoid the effects of a revert commit in another Git branch while merging
- Workflow for handling pull requests in a gitflow workflow (with infrequent releases)?
- Branch model for multiple projects in the same repository?
- Git Flow : Do you have to manually delete the feature branches from remote after finishing the feature?
- Hot-fix during the ongoing release - merge or cherry-pick?
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:
When I add files to one feature’s working copy why do they appear in another feature’s working copy?
What is the point of having feature branches if they can’t isolate changes from each other?
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
Once you have committed the changes, they do not switch between branches any more. You then could merge or cherry pick changes between branches.
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.
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
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.
-u is shorthand for
--include-untracked, which includes newly-created files but not ignored files