So, if anything is still confusing, I’d encourage you to re-read this article and dig into the documentation linked above, as well as try out the examples and everything else you find for yourself. Nota bene: It’s easy to just copy and paste random bits of code that you find on Google to quickly fix the error, but generally speaking it’s much more useful to understand the underlying concepts so that you don’t have to keep Googling the same commands over and over again. git remote add upstream :jigarius/toggl2redmine. git remote add origin :jigarius/toggl2redmine.git Add remote 2: BitBucket. Here’s a real example: Add remote 1: GitHub. To make it easier to pull any changes to update the local copy of the fork from the original repository, many people add the original repository as. Then, the default remote would be origin, in reference to the fork. For further reading, you can find formal documentation on the `git remote` command here. Syntax to add a git remote git remote add REMOTE-ID REMOTE-URL By convention, the original / primary remote repo is called origin. git remote add name URL: Add a remote git remote remove name: Remove a remote. ConclusionĪs I mentioned at the beginning of this article, we broke down the concept of remote repositories in Git and went over a few of the most common commands that you’ll need to understand in order to use them properly. Merging remote upstream changes into your local repository is a common task in Git-based collaboration work flows. And again - the solution is to use `git remote set-url` instead of `git remote add`. The git pull command is used to fetch and download content from a remote repository and immediately update the local repository to match that content. Since “origin” is such a common convention, there’s a good chance that any repository you clone already has a remote configured with this name, because remotes are included when a repository is cloned.Ĭloning a repository and trying to add your own remote server to “origin” without realizing that that name is already in use is a very common way this error is caused. At first glance it’s not obvious whether “origin” is part of the `git remote` command or just a parameter, a misconception that is further supported by the wording of the Git error: it’s not obvious that “origin” is a parameter, and not a part of the failing command.Īnd yes, this means that the error thrown at the top of the article could just as easily read “fatal: remote cheese already exists.” Remote “origin” might've been configured if you cloned the repo It’s frustrating, because this convention is actually the primary source of remote naming errors. It’s worth noting that using “origin” for the name of your default remote repository is simply a convention - you could name your default remote “cheese” for all the difference it would make. “origin” is a convention, not a part of the `git remote` command
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |