Reputation: 55
The project I am working on at the moment uses Git and the Gitflow Workflow methodology. I have hit a stumbling block with Gitflow which, I believe, originates from the underlying functionality of Git. The problem is regarding feature branches.
With Subversion I could create two branches of our repository, check them out to separate Eclipse projects in my workspace and edit them in parallel. I could edit files in both of these projects in isolation from one another. Changes I made to files in one branch would not be reflected in the other, and vice versa.
With Git, I can also create two feature branches in my repository clone. However whenever I create or edit a file in one branch, if I do not commit those changes before switching to the second branch, those changes also appear in the second branch. Likewise, if I then change the same file in the second branch, and switch to the first again, the file contains all of the changes I have made so far, regardless of which branch I was on when the change was made.
To make matters worse, if I then add and commit my changes in the second branch, the file in the second branch will now contain all changes made from the first and second branches, and the changes disappear completely from the first branch!
Is there any way to have feature branches isolated from one another such that files, and changes to files, are not reflected across both feature branches before committing?
I realise that I could simply commit my changes before switching to another branch, or create a separate repository clone for each feature. However both of these approaches seem to defeat the purpose of having branches.
Upvotes: 3
Views: 613
Reputation: 17825
Git now has this feature: it's called git worktree
It allows to have multiple working directories from the same local repository (clone). Each can be on different branches and their working copy, staging area and status are all independent.
Example:
$> pwd
/home/user/my_project
$> git branch
* branch_a
$> git worktree ../my_project_branch_b branch_b
$> git branch
* branch_a
branch_b
$> cd ../my_project_branch_b
$> git branch
branch_a
* branch_b
Upvotes: 2
Reputation: 43800
Unfortunately no. Due to the nature of the branches in git, anything that you have not committed will come along when you switch branches. If you don't want to make a commit, you can also use git stash
to undo your changes temporarily.
This is one of the 'features' of git, you are doing your development in one place and do not have to have multiple copies of the projects in different places. You can switch the branches and not change directories or projects.
Sorry, but you are just going to have to be careful switching branches if you want to use git. Or make them into two separate repos.
Upvotes: 5
Reputation: 3785
Branches in git do not have the same meaning as in subversion or CVS.
Here is a recent experience I had with a colleague: she was using a git repository to manage her project. Before that she used to work with CVS. She created 2 subdirectory, named accordingly to the branch they were supposed to be related. Her workflow was to checkout say branchA and cd to subdirectory A. Then when she wanted to work on feature B, she checked out branchB and cd to subdirectory B.
This is typically a way to work for someone who didn't understand the way git works and who had bad habit with CVS.
When you checkout a branch or a tag in git, this is GLOBAL to the project.
If you want to have 2 concurrent branches of the same project, you must have 2 separate clones of the project, each one checked out in its own branch.
Upvotes: 4