When I call git branch -a I get this output

 aleksey@aleksey:~/Downloads/NTZ/FittingRoom$ git branch -a develop * master remotes/origin/HEAD -> origin/master remotes/origin/master

The develop and master branch is clear that these are my 2 local branches, but it’s clear what

 remotes/origin/HEAD -> origin/master remotes/origin/master

These are remote branches, but what is the difference between them and why one HEAD ... I understand that the head is the branch into which I push, but this should be the master ...

I understand that this should look like this.

 aleksey@aleksey:~/Downloads/NTZ/FittingRoom$ git branch -a develop * master remotes/origin/master

2 local branches and one master remote ...

Why head ?

EDITION. Added another origin/develop branch and after executing the git checkout origin/develop command I get this output via git branch -a

 aleksey@aleksey:~/Downloads/NTZ/FittingRoom$ git branch -a * (detached from origin/develop) develop master remotes/origin/HEAD -> origin/master remotes/origin/develop remotes/origin/master

I understand that HEAD can only point to the branches of the remote repository ... But why then, after switching to the remote branch, does the flow of the devil head still point to the master ??

 remotes/origin/HEAD -> origin/master

Here according to article on Habré

the current state of unchanged files under version control is the commit that HEAD points to

Nitsche is not clear, HEAD in the end points to the branch where you are or the branch in which you made the last commit?

  • 3
    head is a pointer to the current state. See habrahabr.ru/post/157175 - AK ♦
  • four
    Why do you always put github and gitlab tags? - etki
  • @Etki Well, it seemed to me like this question applies to them ... - Aleksey Timoshchenko
  • five
    gitlab and github are just storages that do not change the interface of the gita. - etki

4 answers 4

A branch ( branch ) in git is a (floating) pointer to commit .

HEAD / .git/HEAD (technically) is a file containing a pointer to either the current (for repository) branch (for example, the file may contain such text ref: refs/heads/master ) or the current commit (so called detached head , the file contains a string with the hash sum of this commit .

a remote repository is not “worse” than your local one, and it also has such a file, and information produced by the branch command:

 remotes/origin/HEAD -> origin/master

informs you that this file in the remote repository at the time of the cloning contained a link to the master branch (in the same remote repository).

I understand that the head is the branch in which I make a push

push you do in that branch which you yourself indicated. either explicitly, like this:

 $ git push репозиторий ветка

or implicitly, “linking” your local branch to a (arbitrary) branch in a remote repository, and invoking git push without additional parameters.

You can view the “bindings” of branches, for example, with the remote show репозиторий command:

 $ git remote show origin ... Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date)

about the addition to the question

First, I already answered almost the same question: Why do I get a detached head? .

secondly, I will carry out (and will add) the main thing here:

  1. This line ( remotes/origin/HEAD -> origin/master ) in the output of the branch command appears due to the presence in your local repository of the file refs/remotes/origin/HEAD , containing in your case:

     $ cat .git/refs/remotes/origin/HEAD ref: refs/remotes/origin/master

    You can absolutely painlessly delete this file. then this line will disappear from the output of the branch command.

    This file was created during cloning and contains information about which branch was unpacked in your working directory .

  2. You probably confused this file ( .git/refs/remotes/origin/HEAD ) with the .git/HEAD file, which contains a link to your current branch (or to a commit if your storage is in the “ detached head ” state ).

  3. I understand that HEAD can only indicate the branches of the remote repository.

    not. The .git/HEAD file can store:

    • or a pointer to a local branch (i.e., contain something like ref: refs/heads/master )
    • either a hash of the commit (the so-called “ detached head state”)

  4. But why then, after switching to the remote branch of the girls, the drain of the HEAD still points to the master?

     remotes/origin/HEAD -> origin/master

    I repeat once again: this line appears in the output of the branch command for one reason only - because of the presence of the .git/refs/remotes/origin/HEAD file. This file does not affect anything. You can remove it absolutely painlessly. and then this line will not be in the output of the branch command.

  5. Here according to article on Habré

    the current state of unchanged files under version control is the commit that HEAD points to

    Nitsche is not clear, HEAD in the end points to the branch where you are or the branch in which you made the last commit?

    last commit is absolutely nothing to do with it.

    • if the .git/HEAD file contains a pointer to a local branch (i.e., contains something like ref: refs/heads/master ), then that means that you have unpacked the commit in the working directory pointed to by the local master branch. The hash of this commit is stored in a .git/refs/heads/master file.
    • if the .git/HEAD file contains a commit hash (the so-called “state of detached head ”), then this commit is now unpacked in your working directory .
  • I have never seen such a branch myself ... Can the author's question be related to the fact that his remote repository has a working copy (not a bare )? - Pavel Mayorov am
  • In addition, it is not clear why the remote repository HEAD is generally stretched. For some reason I have always thought that only refs/heads/* “pulled out”, and HEAD does not fall under this pattern. - Pavel Mayorov
  • one
    @PavelMayorov, Can the author's question be related to the fact that his remote repository has a working copy (not a bare)? - most likely it is. At least in my tests, such a line in the output of the branch -r present only in such a situation. - aleksandr barakin
  • @PavelMayorov, only refs / heads / * are “pulled out” - what is specified in the fetch directive in the config file is “pulled out”. the default is +refs/heads/*:refs/remotes/origin/* . Here is the HEAD file in the refs/remotes/origin . and, as far as I can see, it does not change and remains the same as it was created during cloning. - aleksandr barakin
  • one
    @PavelMayorov, stackoverflow.com/q/12613793/4827341 - aleksandr barakin

head is the state of the version you are currently in. that means, if you switch to another branch and you have a head behind other commits, then you need to pull to get the latest version of this branch.

And to switch between branches it is better to use git checkout <branch> , and to view remote branches git remote .

     remotes/origin/master

    This is a read-only thread. Its position indicates the last known (after the last push / pull / fetch ) position of the master branch on the origin server.

     remotes/origin/HEAD -> origin/master

    HEAD in Git is the current top. The local HEAD usually shows the place on the commit graph, which now contains the working tree [0] (for example, checkout is made).

    But here is another case. this is not just HEAD , but from origin . Like all remote branches, it is read only , but what does it indicate?

    In practice, origin/HEAD usually specifies the default branch for the remote repository. There are almost no practical consequences, except when cloning a repository, the local HEAD will be in the same place where at the time of the cloning there was a HEAD on the server. When you work on your machine, you do not need origin/HEAD .

    The situation becomes a bit more interesting when there is an access interface to the remote repository. For him, HEAD can mean something else. For example, on GitHub origin/HEAD or, as they have called, the default branch can be selected in the settings, and you can read the explanation of what it is for:

    If you specify a different branch, it is considered a “base” branch.

    ("The default branch is considered the" main "branch in your repository, into which all pull-requests and commits are made, if you do not explicitly select another branch."

    Why is origin/* read only? These branches are a "reflection" [1] of what is on the origin server. Therefore, these branches change only when your actions change the repository in origin . Say, in the process of push Git sends commits to the server, waits for its acknowledgment of receipt and shifts the "reflection" to a new point. Any changes bypassing this mechanism risk breaking the very essence of origin/* as reflections.

    If you move to the reflection branch (via checkout ), Git will notice that you cannot change it [2] , so HEAD will not go to the branch , but to the commit it is on, separated from the branches (hence detached HEAD ). And from this moment you have to be careful.

    the current state of unchanged files under version control is the commit that HEAD points to

    I hope it is clear from the text above that you have HEAD (your) and origin/HEAD (deleted). In the article about the first. And in the list of branches there is only the last one.

    [0] actually the opposite is true, the working tree is in itself, and HEAD needed to calculate and record the changes made, this is the "starting point"
    [1] this term is honestly coined by me, use it carefully
    [2] everything is possible, but many things break so much that it is not worth it

    • Reflection is a great term. Much better than "remote branches". - Nick Volynkin ♦

    HEAD is the current thread. For example, your branch is called Aleksey_Timoshchenko, and in order not to write this long name, you can, while in it, write HEAD:

    git push origin HEAD

    This line will add changes to the current branch.

    • one
      This is just about the local HEAD . The question is HEAD from the server, it is a completely different thing. - D-side
    • That is, the server HEAD is a pointer to the "main" branch on the server? - Mae
    • one
      Yeah, right. This branch, for example, will be in the working tree after cloning the repository. Other applications have not yet been found (in any case, by me). - D-side