GitHub: Working on two branches locally

Question

I am using the GitHub application for Windows, and it's working great. However, I'm confused how I can work on multiple branches at the same time on my local files.

Let's say that I cloned a repository to C:\github, if I create a new branch nothing changes in my file structure. Meaning that whenever I change a file, it should also change for the master branch, right?

How can I have two branches locally on my machine that I can work on seperately, without having any conflicts. So that when I change file X in branch A, X hasn't changed in the master branch?

• note I'm quite new to GitHub and GH desktop.
• note I'm talking about the file system, not about commits.

Palaeozoology

git-scm.com/docs/git-worktree – Trisomic

Changes are not branch specific until you commit them on that branch. – Illconsidered

@TimCastelijns I get that, but they are filesystem specific. As soon as I change a file (whether I commit or not), it is changed. Right? It seems that I indeed need something like worktree. – Palaeozoology

As soon as I change a file (whether I commit or not), it is changed. Right? - of course, by definition – Illconsidered

The easiest way to work on two branches at the same time is to have two workspaces working on separate cloned repositories. If you don't want to do that then you have to stash or commit any changes made in the workspace to be able to checkout a different branch. – Contort

I know that this is an old post, but I have the same question as it relates to working on files on the local file system. As you said, if I have one set of files and I change them, it doesn't matter whether I'm on master or a branch, the files are changed. Maybe I'm thinking about git's usage incorrectly. If I've committed/merged many changes to master, what if I want to go back say 5 changes in master. Does that revert my files back to how they were 5 changes/merges ago? – Wilsonwilt

Answer 1

The behavior you're asking for is the default behavior for git. When you create a new branch, you're effectively saying that you want to fork the development history from the point where you create the branch. Once you checkout a branch, all work done on files will happen in that branch.

To make this more concrete, imagine you have cloned a repository and just have one branch called master. To create and checkout a new branch, you would do:

git checkout -b new_branch

Now, you would modify file X as desired, add it, commit it, and if you want to share it with others, push it. Now, to see the version of X before the changes you made, simply return to the master branch:

git checkout master

Cortie

Yes, but this doesn't take the local filesystem into account, right. As soon as I change a file, it has been changed (whether commited or not) and GH Desktop will tell me the file has changed and asks me to commit or not. Disregarding these changes will return the file to a previous state. – Palaeozoology

@BramVanroy, what you say is true and what I say is true. I don't see the problem. The file will be viewed as changed. If you discard those changes they will be discarded. If you commit them on a branch, you can change to another state of your git repository by changing branches. Please clearly say what the problem is – Cortie

Answer 2

I do not feel others have answered this question. I have now encountered the same issue. I have found two possible solutions.

OPTION A

A) Create a separate user account on your desktop so you can have multiple branches locally. This is not an optimal solution.

OPTION B (note that B1 and B2 are both part of option B and are different steps)

B1) Create your local repository as normal, rename the directory to indicate that it's a different branch. Then, go to Repository > remove. That way you can clone a second time and repeat. Now you'll have two local branches, neither of which are recognized by github desktop, even though they might be in the same directory as your other github projects. Now work on these branches with whatever external editing programs you want.

B2) When ready to upload, in github desktop choose "add an existing repository from your harddrive", navigate to the branch you want to upload. Add it. Github desktop will recognize the repository. Now you can upload to the branch of your selection using the dropdown at the top. Finally, go to repository > remove again, at the top. Then continue your editing as desired.

Option B is extensible to an arbitrary number of branches, and does not require you to reinstall all of your environments.

Nashbar

Answer 3

Don't concentrate on the file system. The file is changed of course, in the branch it is checked out currently. Just checkout the branch you want to work in before changing files and then work with the files. After commiting you can checkout to another branch.

Superimposed

Answer 4

You can create one simple local branch from master, try to read a little about gitflow and if it gets complicated for you, you might also use SourceTree that will manage your branch creation for you.

So, now lets say you changed many files on the local machine, you can commit them without need to modify your master unless you synchronize it (merge it). So, you can work on different copies of your master without modify master itself, unless you want to

Avisavitaminosis

Answer 5

Let me clarify the real use case, in the hope it help understanding: Several answers above states what happens when you work only on one branch, but if you time-share on several dev tracks (e.g. a bug and a new feature), you do have to switch to another branches back and forth. The versions of common files are well handled by git, but all files of the first branch that do not exist on the second branch are present on the local file system, and appears in changes as untracked, which is not blocking, if you just stage your changes on that branch, but it may be difficult to avoid mistakes.

The user ask for a way to switch the local repo at the same time one switch branch. One shall also prevent conflict whenever branches eventually merge.

I vote for the suggestion of keep away all the changes that appears after the branch switch with a message like git stash push -m "<branch-name>_specific" , and after switch back, stash pop it.

Another option, only for new file that are specifically git ignored in their branch, is to include them in the .gitignore on the other branch, which is just an anticipation of future merge.

Horseshoe