1

I recently started working on a project which uses Git for version control. I have to fix two defects, Defect1 and Defect2. Fixes for Defect1 and Defect2 need changes to File1 and File2 respectively. These two files are unrelated to each other.

I want to work on each defect in a separate Git branch. I created two branches, fix_Defect1 and fix_Defect2, and want to work on them independently. The fixes are complex, so I cannot complete one fix and commit it before switching to the other. I observe that when I switch from fix_Defect1 to fix_Defect2, any changes made to File1 also appear (and vice versa). Is there some way to avoid this from happening?

From the Git help, I could not figure out any way. I also searched on SO for git work with multiple branches, and found Git and working on multiple branches and Using git with multiple branches at once, which are close but somewhat different from my question.

I can clone multiple copies of the repository per branch in a separate directory, but it seems like I would be missing the full power of Git branching by doing so, besides wasting disk space. Could you please suggest a good approach to handle this scenario?

Community
  • 1
  • 1
Masked Man
  • 1
  • 7
  • 40
  • 80

1 Answers1

3

Your problem arises from the fact that you're changing files in the working directory (e.g. file1 and file2) but are not committing or stashing those changes. The best solution is to commit the changes when you feel like switching branches:

git add file1 file2 ;# add whichever ones you've fixed
git commit ;# commit the work in progress
git checkout fix_Defect2 ;# now checkout the other branch

Of course, kitchen sink commits, those that include work in progress and possibly broken code, aren't particularly good for your history. You can always use git rebase to clean up your history later. See, for example, this answer for details or this answer for the philosophy behind it.

Finally, if you don't like the idea of committing your work, you can also use git stash to get something like the same result:

git stash ;# when you're ready to switch
git checkout fix_Defect2 ;# work on this branch for a while
git commit -A ;# be sure to commit your work on 'fix_Defect2'
git checkout fix_Defect1 ;# checkout the original branch
git stash pop ;# reapply the work you stashed from the working directory

I don't recommend the stashing solution, generally. The stashing machinery isn't terribly robust, and is more designed for situations where you need to hotfix something, not balance two equally complex feature branches.

For more details, check out the "File Status Lifecycle" diagram in the git-scm docs.

Community
  • 1
  • 1
Christopher
  • 42,720
  • 11
  • 81
  • 99
  • I tried with `commit` like you said and that does indeed work. Maybe because of my experience with CVS, I found it odd to commit when the code is not ready (even though its a local commit). This is now clear to me. Thanks for this helpful answer. – Masked Man Sep 16 '12 at 12:27
  • 1
    @ap. Happy to help. Keep in mind that the principle in git is the same: Commits should be well engineered, intelligently chunked, a usefully ordered. That written, things like `rebase` make it stupid easy to reconstruct history post-facto. Generally, any feature branch I author goes through 2-3 revisions before I "get it right", which isn't a problem at all as long as it's isolated to my computer. – Christopher Sep 16 '12 at 12:47