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 make a branch exactly as another without making any changes to existing commits?
github - Using git push to create remote branch on the fly without creating local branch - Unix & Linux Stack Exchange
Switch Git branch without files checkout - Stack Overflow
git - Commit a file to a Different Branch Without Checkout - Stack Overflow
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.
I was able to pull changes from origin/master into master while working in another branch by using this command:
git fetch origin master:master
For a deeper dive into what's going on, check out the excellent answer to this Stack Overflow question. The main take-away for me was that this command only works for a fast-forward merge.
You can use git stash before checking out master and pulling, and after checking out live again use git stash pop (or if your git is older, git stash apply and git stash clear assuming you haven't stashed anything else)
Yes, you can do this.
git symbolic-ref HEAD refs/heads/otherbranch
If you need to commit on this branch, you'll want to reset the index too otherwise you'll end up committing something based on the last checked out branch.
git reset
Using basic git commands only:
This answer is a bit longer than that of Charles, but it consists solely of basic git commands that I can understand and thus remember, eliminating the need to keep looking it up.
Mark your current location (commit first if needed):
git checkout -b temp
Reset (moves) the marker to the other branch without changing working dir:
git reset <branch where you want to go>
now temp and other branch point to the same commit, and your working dir is untouched.
git checkout <branch where you want to go>
since your HEAD is already pointing to the same commit, working dir is not touched
git branch -d temp
Note that these commands are also readily available from any graphical client.
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.
The git branch command will let you create a new branch without needing to do any checking out or changes to local files. Then you would need to push the new remote branch.
The specific steps that you would need to do:
git branch master-copy origin/master-- Create a local copy of the branch that you will make into a new remotegit push origin master-copy-- Push the local branch to the remotegit branch -D master-copy-- Delete the local branch copy
All of this is done without doing any checkout of files.
What you need to do is to simply create a remote branch pointing to commit 1.
Short answer
git push origin [commit1 hash]:refs/heads/master-copy
Long answer
Lets say this is you repository:
commit 2 (65bc341) O <-- master
|
(more commits) ...
|
commit 1 (125afe4) O <-- origin/master
To achive what you want you use the git push command, you don't need to create a local branch. You need to pass three parameters to the push command:
git push [REMOTE NAME] [WHERE SHOULD THE REMOTE BRANCH POINT TO]:[REMOTE BRANCH NAME]
Assumming you are following standard names, REMOTE NAME willl probably be "origin".
The REMOTE BRANCH NAME is master-copy.
And finally, WHERE SHOULD THE REMOTE BRANCH POINT TO is the hash of the commit1 (125afe4 in the example I used above)
...so the command would be:
git push origin 125afe4:master-copy
Whith this command you are telling git that in the remote named "origin" you want to create a new branch named "master-copy" pointing to commit 125afe4.
If you run this command (and you did not create any local branch called master-copy) you will get this error
error: unable to push to unqualified destination: master-copy
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'git@WHATEREVER_YOUR_REPO_URL_IS'
Why you get this response? Because git doesn´t know if you are trying to create a branch or a tag in the remote repository. To resolve the ambiguity you run
git push origin 125afe4:refs/heads/master-copy
et voila!
commit 2 (65bc341) O <-- master
|
(more commits) ...
|
commit 1 (125afe4) O <-- origin/master origin/master-copy
If you follow the steps in the accepted answer, the local branch "master-copy" that you create and later delete is the one that resolves the ambiguity. I hope I could provide you with some insights about how git-push works and show you that you don't really need this local branch. You can get what you need with one command instead of three!
Remember, if you want to remove the remote branch later you can run
git push --delete origin master-copy
or you can use the older syntax
git push origin :master-copy