tayabasic.blogg.se - Git meaning

Git meaning update#

For this, git stores this historical information in Troubleshooting broken repositories, or recovering discarded commits that turn It can however be very useful to use this information when you are It's irrelevant in the big picture, but also because it can be seen as privateĭata. The information about when aīranch pointed where is not stored anywhere in the git history. Merge and reset can make it point somewhere else. This is of course not mandatory, forĮxample perl.git doesn't have a master branch, their main branch is calledīlead, because that's what that branch was called before they moved to git.īranch names of course point to different commits all the time. By default git creates aīranch named master when you initialize a repository, and most projects stick

Local branches are the place where you add commits. Tags are also not in a per-remote tree inside the refs/ hierarchy, instead all Will not fetch any tags that already exist locally, even if the values differ. While branches are used to show progress, andīranch heads show the current state, tags are meant to mark a specific point in Push.followtags configuration variable which also ignores lightweight tags. Such as git describe, which by default only looks at annotated tags, or the Mandatory to stick to this, but there are tools that have this rule built in, Lightweight tags can be used for simple local bookmarks. Pointer to a commit, tree or blob, and possibly a GPG signature.Īnnotated tags should be used for tags you want to share, such as releases. A tag object contains a tag message (for example "Version 1.0"), a There are two types of tags: lightweight tags which pointĭirectly to a commit, tree or blob, and annotated tags which point to a tag TagsĪll tags live in refs/tags, both the ones you created locally and the ones youįetched from others. Indication that such an operation is in progress. The existence of the merge, bisect and cherry-pick heads can be used as an

MERGE_HEAD contains all the heads you are currently merging into the current.

In the list marked as usable for merging.

FETCH_HEAD contains a list of all refs you last fetched, with the first one.

SVN2GIT_HEAD is created by git-svnimportĪnd there are two refs that are really special in that they can point to.

BISECT_HEAD is used by git-bisect in some cases.

CHERRY_PICK_HEAD points to the commit you are currently cherry-picking.

Git meaning update#

ORIG_HEAD is sometimes created by tools that update HEAD in a drastic way.

Unlike HEAD, these don't have a reflog, and are mostly used by a single tool There are a few more HEAD-like refs that don't live in the refs/ hierarchy. Symbolic-ref command, not read or write those files directly. To read or update the value ofĪny ref, you must use the git rev-parse, git update-ref and git Implementation detail you must not rely on. There is also special fetch and push behaviour for tags, which is explained They don't see much use, except of course for the HEAD ref. For this reason their usefulness is limited and What its HEAD points to, which git can use when cloning to create

TheyĬan not be fetched or pushed, the only exception is that a remote can advertise Symlinks work (and initially they were actually implemented as symlinks). Symbolic refs do not point to an object, but to another ref similar to how Tags usually point to tag objects or commits, but it's not unheard of for.refs/remotes/remote-name/HEAD are symbolic refs that point to remote-tracking.HEAD (discussed next) is usually a symbolic ref pointing to a local branch.Most refs are a pointer from a name to a commit. So git showīISECT_HEAD or git log v2.6.2 are valid commands. Them anywhere git expects something that looks like a commit. Let's start with the one thing that's the same for all of them: you can use So how many types of refs are there and how do they differ? Turns out, quite a Starting with refs/heads/, tags all start with refs/tags and so on. Git's simple objects-and-refs model allows you to be very creative in naming