How do I work on the same file in GIT but on 2 different branches where I can switch easily between the 2

Is there a way to work on the same file but on different features/branches in GIT? I'm sure there is a way but what is the easiest? I don't want to stash my changes as thats cumbersome. With SVN I was able to work on 2 separate branches as 2 different entities without any intervention and easy to switch between the two.

5 Answers

Answers 1

use the git worktree.

git worktree

Git worktree was introduced in 2007 under the contrib folder in git repo and was called new-workdir.

In git V2.5 it was named worktree and it allow you to have multiple instances of the same repository across different folders.

for example:

git worktree add <second path> 

will create another folder on your computer which allow you to work on different branch simultaneously.

---

If you want to remove the worktree use the prune subcommand

prune
Prune working tree information in $GIT_DIR/worktrees.

Another option to remove it is to delete the .git/worktrees folder

---

If you use rebase later on:

• Note: (Since Git 2.7)
  you can also use the git rebase [--no]-autostash as well.

Answers 2

You seem to be fixated on wanting to do it the Subversion way. I can understand that; changing development habits can be a longish process, and up to a point it may be fine to bend the tools to your own habits instead; that's perfectly fine. So here we go:

Think about it this way: with svn you have one big directory tree where "branches" are not really first class entities but (technically) arbitrary subdirectories

mystuff/trunk mystuff/branches/feature1 mystuff/branches/feature2 ... mystuff/tags/1.0    mystuff/tags/1.1 ... 

So, if you are used this to and happy with it, the exact same solution is possible with git as well, by checking out different copies of the repository in one (non-git) parent:

mystuff/master mystuff/master/.git mystuff/feature1 mystuff/feature1/.git ... 

This is conceptionally exactly the same as before. You keep the different repositories on their respective branch at all times. You'll have a common ancestor to push/pull to/from for merges, as usual (note that this can well be handled locally, no need for a physically remote location, unless you have one anyways; you can/could also in theory use your master repository directly as origin).

What you do not get, and will never get with git, is committing changes in different branches in one go (under one "commit"). A "branch" in git is a fundamentally different thing than in Subversion, the same as a "commit" in git is a fundamentally different thing there (commit != revision). You will have to wrap your head around this, no tool will save you from that.

Some operations:

• Create a new feature branch feature2 (starting at master):

  mystuff> git clone {URL-or-filesystem-path-of-common-origin-repository} feature2 mystuff/feature2> git checkout -b feature2 

• Merge your work from a branch to master:

  mystuff/feature1> git add ... ; git commit ... mystuff/feature1> git push  mystuff/master> git fetch mystuff/master> git merge origin/feature1 

  Same for any other merges; the master branch is technically no different from any other branches in git, it's just a naming convention (like /trunk being a naming convention in Subversion).

• Get rid of a branch:

  mystuff/feature1> git push origin :feature1      # deletes the branch on the common repository mystuff> rm -rf feature1 

All of this uses up a bit more HDD storage than necessary; there are advanced ways to clone a repository locally, re-using the object store. Let me know in a comment if that is of importance to you; unless you really have space constraints, I frankly would not bother.

Answers 3

I don't want to stash my changes as thats cumbersome.

The best way you could go about this is simply editing the file on both branches.

The idea would be to have the common base on your master branch, and add a feature per branch, given your use case.

Answers 4

From what I understood from the comments section: is that you want to have 2 different "versions" of the same file. (As you mentioned on the comments, having file.txt have "AAAAAAA" line on one, and "BBBBBBB" on one, but not "AAAA").

This CAN be achieved by branching very easily.

Before starting your work, you will be "standing" on one branch (probably master). You can at this point create a new branch git checkout -b feature1 (This command creates and switches you to branch feature1). where you will make some changes to file.txt. Say you will write "AAAAAA". Then, you will have to commit it. git commit -a -m "Added the AAAA line". If you now git checkout master (you go back to master). Your file WON'T have "AAAAA" written on it, you can then do other changes to this file (either on this branch, or another branch). You can write "BBBBBBB" to this file, and you will have 2 "versions" of the same file "file.txt", one will have "AAAA" (the one on branch feature1) and the other on master will have BBBB.

Note: I created a scenario where you haven't already changed the file originally, but if you have, there are also ways of achieving this by branching. You should def read https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

Answers 5

I think, that your workflow might be affected by how slow branch switching is in SVN. In Git, you don't need to worry about this - checkout of new branch will take fraction of second (maybe few seconds for very large projects).

The most sensible thing for you would be to work on single branch and once you will do some commits, cherry-pick them to other branch. Example: (let's assume that you want to work on file f.txt, which is identical on both branches)

$ git fetch $ git checkout branch-1 # assuming remote branches exists already $ vim f.txt # do some editing $ git commit -am "f file changed" $ git checkout branch-2 $ git cherry-pick branch-1 # <- this will pick single last commit from branch-1                            # and apply it to branch-2 

You are not limited to picking last commit, of course - you can pick by commit id, tag, you can use ~ operator to select commit ancestor, etc. You can even do many cherry-picks at once by rebasing or, even nicer, interactive rebasing.

After your work is done, you need to do two separate pushes per branch (or you can change your push.default config option to matching to do one push from all local branches).

If You Enjoyed This, Take 5 Seconds To Share It

• Facebook
• Twitter
• Google+
• StumbleUpon
• Digg
• Delicious
• LinkedIn
• Reddit
• Technorati