0

I am currently learning about Git, and have found many, in my opinion, conflicting definitions of what origin are.

My current understanding of origin based on my tutorial, is that every time a file is fetched from the local server, the origin "pointer" moves to the latest commit downloaded from there, and thus I consider it a pointer.

The problem is I've also heard the origin referred to as a branch (Git branching: master vs. origin/master vs. remotes/origin/master) . My question is how can it be considered a "pointer" and branch at the same time, when pointers "points" to an individual commit and branch refers to a change in direction of a branch that allows you to make alterations separate from the current branch, two completely different things.

A branch: 

 master --> a
                \
                 \
          branch1 --> b

A pointer:

master --> a --> b --> c 
                       --> C is the HEAD "pointer" and capable of moving if point D created
Community
  • 1
  • 1
the12
  • 2,395
  • 5
  • 19
  • 37
  • http://stackoverflow.com/questions/9529497/what-is-origin-in-git – David Neiss Aug 04 '16 at 01:39
  • Yes I've read that thread, but that does not explain the difference in my opinion of why specifically an origin can be considered both a pointer and a branch, at least in a reasonable amount of detail. – the12 Aug 04 '16 at 01:42
  • `origin` is the alias of the url or path of the remote repo. – ElpieKay Aug 04 '16 at 01:50

2 Answers2

1

There is nothing in git called an "origin". The label "origin" is simply the name given by default to the automatically configured "remote". Neither is there anything in git called a "pointer", although there are "references".

A remote is a named git repository other than the one you are working in. It may be another directory on the same computer or it may be located on a computer somewhere else in the world. Git knows what branches exist in the remote repository (you can see these when you run git branch -a, which shows both local and remote branches). You refer to remote branches as "remotename/branchname", so if you have a remote named origin and a branch named master, you can check that out by running:

git checkout origin/master

If you simply were to run:

git checkout master

Then (assuming it didn't already exist) git will create a local branch named master and configure to it track origin/master. "Tracking" means that you type git pull, git knows that you want to update origin/master from the remote repository and then merge those changes into your local branch. Similarly, when you type git push, git knows you want to send your changes to the master branch of the remote repository.

A branch is a type of reference that refers to a series of changes. When you make a new commit on a branch, the branch reference advances to the new commit. So if you started with two commits on branch master:

       master
      /
A -> B

And you make a new commit on that branch, you get:

            master
           /
A -> B -> C

Note that in these examples, the branch name refers to the most recent commit.

A tag is another kind of reference. Unlike a branch, a tag changes only when you explicitly update it. So if you had a tag working_version pointing at commit B in the previous example, it would continue to point at commit B even after you made a new commit.

You can find details on the above and more in The Git Book.

larsks
  • 277,717
  • 41
  • 399
  • 399
  • I thought that branches were the name of the entire set of commits from start to finish (the moment you create a branch, that's considered a start and the moment that branch merges or ends that is an end)? i.e.:master A --> B --> C, A, B and C are part of the master branch. According to your definition, only C would be the master branch, and the rest would be nothing? – the12 Aug 04 '16 at 02:01
  • 1
    @rich22 A branch is a reference to a single commit. A branch does not remember where it "started". (Reset operations - which you probably haven't learned about yet - can do things like move a branch to a commit that *precede* where it "started".) Often people think of a branch as referring to "all commits leading to the final one" but technically, a branch is just the final commit. It's not clear to me what you mean by "master A --> B --> C". – Raymond Chen Aug 04 '16 at 02:35
  • Yeah I was talking about my previous understanding of it, which if you consider the following commit tree: A --> B --> C, Commits A, B and C would be considered the branch (like a tree branch) But according to everyone that's kindly responded to this thread, only the most recent commit would be considered the branch, a pointer or reference that is capable of moving depending on what is committed. – the12 Aug 04 '16 at 02:41
  • 1
    The branch points to the most recent commit. That commit has a reference to the previous commit, which in turn has a reference to the previous commit, etc, forming a chain back to the initial commit (along that branch). – larsks Aug 04 '16 at 13:04
1

When you clone a repository, you're essentially copying it from somewhere. That "somewhere" is what git calls the "origin". So, the origin is the source repository you got it from.

Now, after a clone you have a repository on your machine that will probably change independently from the origin (because you will be committing to it). In addition, at some point in the future you will need to re-synchronize your repository with the origin (because you will be publishing your work back to the origin).

So it comes down merging a branch in your repository with the current state of a branch in the origin. It is completely possible that your branch and the origin's branch have the same name (like master) and therefore Git needs a way to differentiate these branches. Again, it chooses a simple approach - prefix the branch name with "origin/".

Therefore, if we use the example of the master branch, "master" is the state of the master branch in your repository and "origin/master" is the state of the master branch in the origin.

One last thing you need to know: every commit has a reference to its parents. So a merge commit would have two or more parents (yes you can merge more than two branches). Because of this, even though a branch points only to the latest commit, it ends up preserving the entire chain of commits necessary to navigate the branch's history.

Note on learning git

Do not try and map git to existing version control concepts. With git, all branches are essentially pointers with names and the repository is nothing but a directed acyclic graph. Think of Git in this way and suddenly everything makes sense.

Carl
  • 43,122
  • 10
  • 80
  • 104