How to work on the multiple different branches where I can switch easily between them?

问题

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 that's 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.

回答1:

use the git worktree.

git worktree

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

In git V2.5 it was named worktree and it allows 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 allows you to work on different branch simultaneously.

---

If you want to remove the worktree, delete the folder and then execute git worktree prune which will remove the worktree reference.

prune
Prune working tree information in $GIT_DIR/worktrees.

Creating new worktree

# create new branch inside the worktree folder 
git worktree -b <branch name> <path>

Removing worktree

# do your code and once you have done 
# commit, push and now you can delete your folder
rm -rf <path>

# Tell git to remove the workdir copy
git worktree prune

Update In the coming versions (git 2.17+) a git worktree delete will be exposed as a new command for deleting worktrees.

Listing worktree

---

If you use rebase later on:

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

回答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.

回答3:

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

回答4:

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.

回答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).

来源：https://stackoverflow.com/questions/38133883/how-to-work-on-the-multiple-different-branches-where-i-can-switch-easily-between