If you have just done git init in a new repository (as opposed to re-init-ing an existing repository), and have not yet run git commit, you are currently on an unborn branch (normally master-as-unborn-branch). What this means is that HEAD contains the name master, while the branch named master does not actually exist.
If you have furthermore not run any git add commands, your index is currently empty.
The state that you would like to have is to have the name master point to the same commit as foo/master, without changing the contents of the work-tree. But first you need to obtain all the commits from remote foo:
$ git fetch foo
Now you can create the branch itself:
$ git branch master foo/master
Since you're already on master—it was merely "unborn"—you are now still on master and master points to the same commit as foo/master.
Your index is still empty, so git status will show you as having deleted every file from the HEAD commit, with every file in the work-tree as an untracked file. If you would like to populate your index from the current commit, you can now do:
$ git read-tree HEAD
and then git reset various files to restore them. If not—if you just want to use the work-tree—you can simply git add . (though you may want to set up a .gitignore first).
How to create a develop branch without committing files to master branch in Git?
How to create new branch on GIthub without checking out locally and pushing? - Stack Overflow
Create local branch without switching to it
Possible to create a new branch without cloning the repo locally?
[SOLVED]
Hi everyone,
I'm new to git and I need some help with a problem I'm facing. I have a project folder with three subfolders: folder 1, folder 2, and folder 3. Each subfolder contains some files that I want to work on.
I want to use git to manage my project, so I created a local repository by running `git init` in the project folder. This created a master branch by default. However, I don't want to commit anything to the master branch yet, because I want to use it for the final product release. Instead, I want to create a develop branch where I can add and commit the subfolders and work on them separately. For example, I want to add folder 1 to the develop branch and work on it without affecting the master branch or the other subfolders.
I tried to create a develop branch by running `git checkout -b develop`, but it didn't let me add any subfolders to it until I added and committed them to the master branch first. This is not what I want, because I don't want to have any subfolders in the master branch at this stage.
How can I solve this problem? How can I create a develop branch and add the subfolders to it without committing them to the master branch first? Is there a way to ignore the subfolders in the master branch or remove them after adding them to the develop branch?
I would appreciate any advice or suggestions from you. Thank you for your time and support.
November 2021 Update: As of git version 2.27, you can now use the following command to create an empty branch with no history:
git switch --orphan <new branch>
Unlike git checkout --orphan <new branch>, this branch won't have any files from your current branch (save for those which git doesn't track).
This should be the preferred way to create empty branches with no prior history.
Once you actually have commits on this branch, it can be pushed to github via git push -u origin <branch name>:
git switch --orphan <new branch>
git commit --allow-empty -m "Initial commit on orphan branch"
git push -u origin <new branch>
Original answer:
What's wrong with the --orphan option? If you want a branch that is empty and have no history, this is the way to go...
git checkout --orphan empty-branch
Then you can remove all the files you'll have in the staging area (so that they don't get committed):
git rm -rf .
At this point you have an empty branch, on your machine.
Before you can push to GitHub (or any other Git repository), you will need at least one commit, even if it does not have any content on it (i.e. empty commit), as you cannot push an empty branch
git commit --allow-empty -m "root commit"
Finally, push it to the remote, and crack open a beer
git push origin empty-branch
--orphan is good for creating an empty branch locally, however, in order to push it or interact with other branches, you will need a commit.
Creating a new commit on an orphan branch is not a good idea because you won't be able to interact with other branches. I.e.
git checkout --orphan test
git commit --allow-empty -m "init test branch"
git merge master
fatal: refusing to merge unrelated histories
Instead, you should prefer creating a new branch from the first commit of master. If the commit is not empty you can add an empty commit before the first one, as explained by @houtanb.
While writing the question, and finding What is the difference between "git branch" and "git checkout -b"? in the list of similar questions, I found the answer myself:
$ git checkout -b new_branch_name
I guess I was reading the man page for the wrong command, I was expecting this as part of the branch command, not for checkout. Quoting the man page for checkout:
Specifying
-bcauses a new branch to be created as ifgit-branch(1)were called and then checked out.
Just what I was looking for.
Git introduced switch in version 2.23 to handle changing of branches specifically and avoid the use of checkout which can be confusing by the sheer amount of operations it can do.
Among other possibilites,
git switch <branch> # to switch to an existing branch
git switch -c <new_branch> # to create a new branch and switch to it
As several others have said, it is literally possible, but impractical.
However, as of Git 2.5 (with some important fixes in 2.6 and minor ones since then), there is a practical method for doing this using git worktree add.
Let's say, for instance, that you want to work on branches main and doc "at the same time", or branches develop and test "at the same time", but the two branches in question deliberately contain different things. (For instance, the doc branch has documentation that exists outside or alongside the code, or the test branch has tests that will be run against the code, but not distributed, or which are expected to have failures for which tests are deliberately skipped on the develop side, or whatever.)
Instead of just:
git clone -b develop <source> theclone
followed by working in theclone with constant switching back and forth between the two branches, you would:
git clone -b develop <source> theclone
but then:
cd theclone
git worktree add ../ct test # check out branch test in ../ct
or just:
git worktree add ../test # check out branch test in ../test
Now you can run your tests in ../test while developing in theclone. You can merge and/or rebase changes from one branch to the other in the usual way: the underlying repository is already shared, so no git push or git fetch is required. You simply have both branches checked out, into two separate work-trees, named theclone and test from the top level.
It's not possible.
The changes you commit are related to the current working copy. If you want to commit to another branch it means that you could commit changes from your working copy, but base them from another copy state.
This is not a natural way of versioning your work, and this is why you need to make different steps (stash changes, checkout the branch, pop stash and commit) to accomplish it.
As for your specific use case, a simple way is to keep two copies of your work, one checked out at master branch, and the other at pages branch.
In the pages working copy, add the master copy as a remote repo.
- You commit pages on
master - Pull from
masteron thepagescopy - push to GitHub
- reset the master branch at its previous state.
I have two branches, master and feature. Is there a git command equivalent of switching to feature, copying the contents of the entire repo, switching to master, deleting everything in the repo, and pasting the copied contents?
I want the master branch to be exactly the same as feature but the changes needed to achieve this should appear as a single commit in master branch after the latest existing commit in master.