Using git I would like to go into detached HEAD state and create a new commit. I'd then like to create a tag and push both the 'detached commit' and the tag to the remote repo. Is this possible?
If I create the detached commit in my local repo and create a tag then I can checkout the tag to get back to that state. I'd like to share that with the remote repo so that other uses can clone the repo and checkout the tag and get to that same state.
The reason I want to do this is because the build process needs to capture the build # in a file but I don't want to commit that to the branch where development is ongoing. I want the commit to be separate, but also want to capture the commit and tag it so that anyone can checkout the tag and the files that are included in the build. Is it recommended to push the commit to different branch, say "build"?
Commit your changes to a new branch If you do any work on the repository and want to create any commits during the detached HEAD state, it's not a problem. You just need to create a new branch and push your commits there.
It just means you are not currently attached to any branch, and as a result, your HEAD is detached. If you want to keep the changes you made while in the detached HEAD state, you can solve this problem with three simple steps: creating a new branch, committing the changes, and merging the changes.
Any checkout of a commit that is not the name of one of your branches will get you a detached HEAD. A SHA1 which represents the tip of a branch still gives a detached HEAD. Only a checkout of a local branch name avoids that mode. When HEAD is detached, commits work like normal, except no named branch gets updated.
to get out of detached HEAD state. Generally speaking: git checkout <branchname> will get you out of that. This also tries to check out your last checked out branch.
Yes, this—by "this" I mean the main question, "can you push a tagged but not branch-contained commit?"—is perfectly fine. Note that git push
works by calling up some other Git (e.g., ssh://... or https://... call up the other Git over the Internet-phone), delivering some commit(s) if necessary, and then asking that other Git: "please set a reference name to point to some specific commit(s)".
Since you have a tag, you can ask that other Git to please set the same tag. Assuming the remote is named origin
(as it typically is):
git push origin <tag>
You can spell out the full name, refs/tags/tag
, if needed. If tag names are easily distinguished from branch names (e.g., tags are v2.x
and branches never start with v
) it won't ever be needed (but it might still be wise in general).
If you did not have a tag, you could still do it, but you would have to provide the other Git a name. To do that, you would do something like:
git push origin HEAD:refs/heads/newbranch
or:
git push origin HEAD:refs/tags/newtag
The tricky bit here is that during the push, you have no idea whether they have a branch newbranch
or tag newtag
already. If you've set a tag yourself, and have also been fetching from them all along, you probably have a good idea—not a guarantee, of course—that they do not have that tag yet either.
Note that if they do have that name, and you politely request that they change their name to point to some other commit, they may refuse. This is when you see rejected
errors from push. You can command them (using git push --force
or the +
prefix syntax on a refspec), but that's usually not the right way to go, plus they can still refuse (that part is up to whoever controls the other Git).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With