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.

  • Understanding Git Branches graph view
  • is git submodules what I need?
  • Error Pushing to Remote Git Repo
  • Can SourceTree show diff side-by-side
  • how do i search bitbucket files that contain a string and are contained in specific repos?
  • How to check if a commit has been merged to my current branch - somewhere in time?
  • 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 Diff of same files in two directories always result in “renamed”
  • move branch from master commit to previous master commit
  • npm scripts ignore errors
  • Practical uses of git reset --soft?
  • How to output git log with the first line only?
  • What are typical use cases of git-reset's --merge and --keep flags?
  • 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.