Git how to see origin
Git how to see origin
Git how to see origin
Check your version of git by running
SYNOPSIS
DESCRIPTION
Manage the set of repositories («remotes») whose branches you track.
OPTIONS
Be a little more verbose and show remote url after name. For promisor remotes, also show which filter ( blob:none etc.) are configured. NOTE: This must be placed between remote and subcommand.
COMMANDS
With no arguments, shows a list of existing remotes. Several subcommands are available to perform operations on the remotes.
By default, only tags on fetched branches are imported (see git-fetch[1]).
Changes the list of branches tracked by the named remote. This can be used to track a subset of the available remote branches after the initial setup for a remote.
Retrieves the URLs for a remote. Configurations for insteadOf and pushInsteadOf are expanded here. By default, only the first URL is listed.
Note that the push URL and the fetch URL, even though they can be set differently, must still refer to the same place. What you pushed to the push URL should be what you would see if you immediately fetched from the fetch URL. If you are trying to fetch from one place (e.g. your upstream) and push to another (e.g. your publishing repository), use two separate remotes.
See the PRUNING section of git-fetch[1] for what it’ll prune depending on various configuration.
DISCUSSION
The remote configuration is achieved using the remote.origin.url and remote.origin.fetch configuration variables. (See git-config[1]).
EXIT STATUS
On any other error, the exit status may be any other non-zero value.
EXAMPLES
Add a new remote, fetch, and check out a branch from it
Imitate git clone but track only selected branches
Working with Remotes
To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. In this section, we’ll cover some of these remote-management skills.
Showing Your Remotes
To see which remote servers you have configured, you can run the git remote command. It lists the shortnames of each remote handle you’ve specified. If you’ve cloned your repository, you should at least see origin – that is the default name Git gives to the server you cloned from:
If you have more than one remote, the command lists them all. For example, a repository with multiple remotes for working with several collaborators might look something like this.
This means we can pull contributions from any of these users pretty easily. We may additionally have permission to push to one or more of these, though we can’t tell that here.
Notice that these remotes use a variety of protocols; we’ll cover more about this in Getting Git on a Server.
Adding Remote Repositories
I’ve mentioned and given some demonstrations of adding remote repositories in previous sections, but here is how to do it explicitly. To add a new remote Git repository as a shortname you can reference easily, run git remote add [shortname] [url] :
Now you can use the string pb on the command line in lieu of the whole URL. For example, if you want to fetch all the information that Paul has but that you don’t yet have in your repository, you can run git fetch pb :
Paul’s master branch is now accessible locally as pb/master – you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. (We’ll go over what branches are and how to use them in much more detail in Git Branching.)
Fetching and Pulling from Your Remotes
As you just saw, to get data from your remote projects, you can run:
The command goes out to that remote project and pulls down all the data from that remote project that you don’t have yet. After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time.
If you clone a repository, the command automatically adds that remote repository under the name “origin”. So, git fetch origin fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. It’s important to note that the git fetch command pulls the data to your local repository – it doesn’t automatically merge it with any of your work or modify what you’re currently working on. You have to merge it manually into your work when you’re ready.
If you have a branch set up to track a remote branch (see the next section and Git Branching for more information), you can use the git pull command to automatically fetch and then merge a remote branch into your current branch. This may be an easier or more comfortable workflow for you; and by default, the git clone command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. Running git pull generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you’re currently working on.
Pushing to Your Remotes
This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. You’ll have to pull down their work first and incorporate it into yours before you’ll be allowed to push. See Git Branching for more detailed information on how to push to remote servers.
Inspecting a Remote
That is a simple example you’re likely to encounter. When you’re using Git more heavily, however, you may see much more information from git remote show :
Removing and Renaming Remotes
If you want to remove a remote for some reason – you’ve moved the server or are no longer using a particular mirror, or perhaps a contributor isn’t contributing anymore – you can use git remote rm :
How can I find the location of origin/master in git, and how do I change it?
I am also using unfuddle.com to store my code. I make changes on my Mac laptop on the train to/from work and then push them to unfuddle when I have a network connection using the following command:
I use Capistrano for deployments and pull code from the unfuddle repository using the master branch.
Lately I’ve noticed the following message when I run «git status» on my laptop:
And I’m confused as to why. I thought my laptop was the origin. but don’t know if either the fact that I originally pulled from Subversion or push to Unfuddle is what’s causing the message to show up. How can I:
My mac is running Git version 1.6.0.1.
When I run git remote show origin as suggested by dbr, I get the following:
Now, interestingly, I’m working on my project in the geekfor directory but it says my origin is my local machine in the gf directory. I believe gf was the temporary directory I used when converting my project from Subversion to Git and probably where I pushed to unfuddle from. Then I believe I checked out a fresh copy from unfuddle to the geekfor directory.
So it looks like I should follow dbr’s advice and do:
13 Answers 13
Trending sort
Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.
It falls back to sorting by highest score if no posts are trending.
Switch to Trending sort
I came to this question looking for an explanation about what the message «your branch is ahead by. » means, in the general scheme of git. There was no answer to that here, but since this question currently shows up at the top of Google when you search for the phrase «Your branch is ahead of ‘origin/master'», and I have since figured out what the message really means, I thought I’d post the info here.
So, being a git newbie, I can see that the answer I needed was a distinctly newbie answer. Specifically, what the «your branch is ahead by. » phrase means is that there are files you’ve added and committed to your local repository, but have never pushed to the origin. The intent of this message is further obfuscated by the fact that «git diff», at least for me, showed no differences. It wasn’t until I ran «git diff origin/master» that I was told that there were differences between my local repository, and the remote master.
«your branch is ahead by. « => You need to push to the remote master. Run «git diff origin/master» to see what the differences are between your local repository and the remote master repository.
Hope this helps other newbies.
(Also, I recognize that there are configuration subtleties that may partially invalidate this solution, such as the fact that the master may not actually be «remote», and that «origin» is a reconfigurable name used by convention, etc. But newbies do not care about that sort of thing. We want simple, straightforward answers. We can read about the subtleties later, once we’ve solved the pressing problem.)
What is «origin» in Git?
What exactly is origin and why do I have to type it before the branch name?
13 Answers 13
Trending sort
Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.
It falls back to sorting by highest score if no posts are trending.
Switch to Trending sort
origin is an alias on your system for a particular remote repository. It’s not actually a property of that repository.
you’re saying to push to the origin repository. There’s no requirement to name the remote repository origin : in fact the same repository could have a different alias for another developer.
Remotes are simply an alias that store the URL of repositories. You can see what URL belongs to each remote by using
In the push command, you can use remotes or you can simply use a URL directly. An example that uses the URL:
origin is not the remote repository name. It is rather a local alias set as a key in place of the remote repository URL.
It avoids the user having to type the whole remote URL when prompting a push.
This name is set by default and for convention by Git when cloning from a remote for the first time.
This alias name is not hard coded and could be changed using following command prompt:
Take a look at http://git-scm.com/docs/git-remote for further clarifications.
Git has the concept of «remotes», which are simply URLs to other copies of your repository. When you clone another repository, Git automatically creates a remote named «origin» and points to it.
origin is the default alias to the URL of your remote repository.
Simple! «origin» is just what you nicknamed your remote repository when you ran a command like this:
From then on Git knows that «origin» points to that specific repository (in this case a GitHub repository). You could have named it «github» or «repo» or whatever you wanted.
Origin is the shortname that acts like an alias for the url of the remote repository.
Let me explain with an example.
Because you cloned the repository. The remote repository and the local repository are linked.
Now, this may be a bit confusing because in GitHub (or the remote server) the project is called ‘amazing-project’. So why does it seem like there are two names for the remote repository?
Well one of the names that we have for our repository is the name it has on GitHub or a remote server somewhere. This can be kind of thought like a project name. And in our case that is ‘amazing-project’.
Basically origin is the default shortname that Git uses for a remote repository when you clone that remote repository. So it’s just the default.
In many cases you will have links to multiple remote repositories in your local repository and each of those will have a different shortname.
So final question, why don’t we just use the same name?
I will answer that question with another example. Suppose we have a friend who forks our remote repository so they can help us on our project. And let’s assume we want to be able to fetch code from their remote repository. We can use the command git remote add in order to add a link to their remote repository in our local repository.
In the above image you can see that I used the shortname friend to refer to my friend’s remote repository. You can also see that both of the remote repositories have the same project name amazing-project and that gives us one reason why the remote repository names in the remote server and the shortnames in our local repositories should not be the same!
There is a really helpful video 📹 that explains all of this that can be found here.
Git how to see origin
Once you have a Git repository, either one that you set up on your own server, or one hosted someplace like GitHub, you can tell Git to either push any data that you have that is not in the remote repository up, or you can ask Git to fetch differences down from the other repo.
You can do this any time you are online, it does not have to correspond with a commit or anything else. Generally you will do a number of commits locally, then fetch data from the online shared repository you cloned the project from to get up to date, merge any new work into the stuff you did, then push your changes back up.
docs book git remote list, add and delete remote repository aliases
So that you don’t have to use the full URL of a remote repository every time you want to synchronize with it, Git stores an alias or nickname for each remote repository URL you are interested in. You use the git remote command to manage this list of remote repos that you care about.
git remote list your remote aliases
You see the URL there twice because Git allows you to have different push and fetch URLs for each remote in case you want to use different protocols for reads and writes.
git remote add add a new remote repository of your project
For example, if we want to share our Hello World program with the world, we can create a new repository on a server (Using GitHub as an example), which should give you a URL, in this case «git@github.com:schacon/hw.git». To add that to our project so we can push to it and fetch updates from it we would do this:
git remote rm removing an existing remote alias
git remote rename [old-alias] [new-alias] rename remote aliases
In a nutshell with git remote you can list our remote repositories and whatever URL that repository is using. You can use git remote add to add new remotes, git remote rm to delete existing ones or git remote rename [old-alias] [new-alias] to rename them.
git remote set-url update an existing remote URL
Should you ever need to update a remote’s URL, you can do so with the git remote set-url command.
For example, we’ll update the github remote but instead reference it as guhflub in both invocations.
docs book git fetch download new branches and data from a remote repository
docs book git pull fetch from a remote repo and try to merge into the current branch
Assuming you have a remote all set up and you want to pull in updates, you would first run git fetch [alias] to tell Git to fetch down all the data it has that you do not, then you would run git merge [alias]/[branch] to merge into your current branch anything new you see on the server (like if someone else has pushed in the meantime). So, if you were working on a Hello World project with several other people and wanted to bring in any changes that had been pushed since we last connected, we would do something like this:
Here we can see that since we last synchronized with this remote, five branches have been added or updated. The ‘ada’ and ‘lisp’ branches are new, where the ‘master’, ‘c-langs’ and ‘java’ branches have been updated. In our example case, other developers are pushing proposed updates to remote branches for review before they’re merged into ‘master’.
In a nutshell you run git fetch [alias] to synchronize your repository with a remote repository, fetching all the data it has that you do not into branch references locally for merging and whatnot.
docs book git push push your new branches and data to a remote repository
To share the cool commits you’ve done with others, you need to push your changes to the remote repository. To do this, you run git push [alias] [branch] which will attempt to make your [branch] the new [branch] on the [alias] remote. Let’s try it by initially pushing our ‘master’ branch to the new ‘github’ remote we created earlier.
Pretty easy. Now if someone clones that repository they will get exactly what we have committed and all of its history.
What if you have a topic branch like the ‘erlang’ branch created earlier and want to share just that? You can just push that branch instead.
Now when people clone or fetch from that repository, they’ll get an ‘erlang’ branch they can look at and merge from. You can push any branch to any remote repository that you have write access to in this way. If your branch is already on the server, it will try to update it, if it is not, Git will add it.
This is what happens when you try to push a branch to a remote branch that has been updated in the meantime:
You can fix this by running git fetch github; git merge github/master and then pushing again.
In a nutshell you run git push [alias] [branch] to update a remote repository with the changes you’ve made locally. It will take what your [branch] looks like and push it to be [branch] on the remote, if possible. If someone else has pushed since you last fetched and merged, the Git server will deny your push until you are up to date.