{"id":898,"date":"2021-02-23T19:41:25","date_gmt":"2021-02-23T19:41:25","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=898"},"modified":"2021-02-23T19:41:25","modified_gmt":"2021-02-23T19:41:25","slug":"set-git-upstream-respository-branch","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=898","title":{"rendered":"How to set Git Upstream For a Respository and a Branch"},"content":{"rendered":"

In this blog, you will learn everything about setting up an upstream<\/strong> for a git<\/a> repository, a branch and the --set-upstream-to<\/code> command usage<\/p>\n

You will also learn about different scenarios where git upstream is used and how to apply it in your git development workflow.<\/p>\n

Have you wondered how to keep the forked repo in sync with the main repo<\/strong>? It’s done by adding the main repo as the upstream. It is explained in the below sections.<\/p>\n

What is Upstream in Git?<\/h2>\n
\n
Note: <\/strong><\/b>We are following the name “main” instead of “master” considering the removal of terms like “master” and “slave” in the IT community.<\/div>\n<\/div>\n

Like the literal meaning, upstream refers to something which points to where it originated from.<\/p>\n

In the git world, upstream refers to the original repo or a branch. For example, when you clone from Github, the remote Github repo is upstream for the cloned local copy.<\/p>\n

Let’s take a look at different types of git upstreams.<\/p>\n

Git Repository Upstream<\/h3>\n

Whenever you clone a git repository, you get a local copy in your system. So, for your local copy, the actual repository is upstream.<\/p>\n

\"git<\/figure>\n

Git Forked repository Upstream<\/h3>\n

When you clone a Forked repository to your local, the forked repository is considered as the remote origin, and the repository you forked from is upstream.<\/p>\n

This workflow is common in open-source development and even in normal project developments.<\/p>\n

For example, If you wanted to contribute to an open-source project, this is what you do.<\/p>\n

    \n
  1. You would fork the actual project repository.<\/li>\n
  2. Then you clone from the forked repository.<\/li>\n
  3. Meanwhile, to keep up with the main open-source repository, you pull the changes from it through your git upstream config.<\/li>\n
  4. You push your changes to a branch in the forked repository.<\/li>\n
  5. Then you would raise a PR to the actual project repository from your forked repository. <\/li>\n<\/ol>\n
    \"\"<\/figure>\n
    \n
    Tip:<\/strong><\/b> With Jenkins multibranch pipelines, you can easily set up<\/a> the hooks for pull requests from a Forked branch.<\/div>\n<\/div>\n

    Setup Git Upstream For a Repository<\/h2>\n

    Let’s say you are working on a forked project and you want to sync changes from the main project repo.<\/p>\n

    You can add the actual repo as an upstream to your local copy. This way you can pull all the changes happening in the main project repo.<\/p>\n

    Add an Upstream Repo<\/h3>\n

    Before adding upstream, you can take a look at your .git\/config<\/code> file and you will see something like below with a remote origin. Which is a clone of the forked repo.<\/p>\n

    \"git<\/figure>\n

    Now lets the add the upstream to our repo with the main project repo URL using the add upstream<\/code> command.<\/p>\n

    git remote add upstream https:\/\/github.com\/devopscube\/vagrant-examples.git<\/code><\/pre>\n
    Now if you check the .git\/config<\/code>, you will see an upstream entry as shown below.<\/p>\n
    \"git<\/figure>\n
    You can also check out the remote origin and upstream branches using the following command.<\/p>\n
    git branch --remotes<\/code><\/pre>\n
    Here is a sample output.<\/p>\n
    vagrant@dcubelab:~\/vagrant-examples$ git branch --remotes\n  origin\/HEAD -> origin\/main\n  origin\/dev\n  origin\/main\n  upstream\/dev\n  upstream\/main<\/code><\/pre>\n
    Sync Changes From The Upstream repo<\/h3>\n
    To sync an upstream repo, first, you need to fetch the upstream changes.<\/p>\n
    git fetch upstream<\/code><\/pre>\n
    Then, merge the changes from the upstream branch to the local branch. In this example, it’s the main upstream branch.<\/p>\n
    git merge upstream\/main<\/code><\/pre>\n
    Setup Git Upstream For a Branch<\/h2>\n
    But when we talk about an upstream branch, it refers to the specific upstream of a branch in the remote respository.<\/p>\n
    For example, let’s say you clone a git repository with two branches, main and dev<\/strong>.<\/p>\n
    When you clone the repository both the branches, main, and dev will have the respective upstream branches (remote branches) because these branches are present in both the local copy as well the remote or upstream repository. Also, the tracking is enabled by default.<\/p>\n
    Now let’s look at scenarios where you want to set up git upstream using --set-upstream-to<\/code> command.<\/p>\n
    \n
    Important Note:<\/strong><\/b> In git version update, 1.8.0 the --set-upstream<\/code> the command is changed to --set-upstream-to<\/code><\/div>\n<\/div>\n
    Add Git Upstream Using –set-upstream-to<\/h3>\n
    When you create a branch (named foo)  in your local repository and want to add an upstream branch for tracking,  you can use the following command.<\/p>\n
    git push -u origin foo<\/code><\/pre>\n
    \n
    Important Note:<\/strong><\/b> Here -u<\/code> is the shorthand for --set-upstream-to<\/code><\/div>\n<\/div>\n
    When you push a local branch with the upstream command, it automatically creates the remote branch and adds tracking to your local branch.<\/p>\n
    Add Git Upstream To Existing Remote Branch<\/h3>\n
    Sometimes, when you create a local branch, you might push the remote repository changes without adding the upstream tag. For example,<\/p>\n
    git push origin foo<\/code><\/pre>\n
    It will create the remote branch without tracking. Meaning, when someone pushes any change to the branch foo in the remote branch, and when you try to pull the changes, it will throw the following error.<\/p>\n
    There is no tracking information for the current branch.\nPlease specify which branch you want to merge with.\nSee git-pull(1) for details\n\n    git pull <remote> <branch>\n\nIf you wish to set tracking information for this branch you can do so with:\n\n    git branch --set-upstream-to=origin\/<branch> testing<\/code><\/pre>\n
    To avoid this, you can set git upstream using the following command. It will enable tracking, and you will be able to pull the changes.<\/p>\n
    git branch --set-upstream-to origin\/foo<\/code><\/pre>\n
    Add Git Upstream Using Git HEAD<\/h3>\n
    In git, HEAD refers to the currently active branch.<\/p>\n
    For example, if you have checked out foo<\/code> branch, your HEAD now is foo<\/code>.<\/p>\n
    So when you create a new local branch named foo, you can create the upstream using the HEAD as shown below.<\/p>\n
    git push -u origin HEAD<\/code><\/pre>\n
    Git set-upstream FAQ’s<\/h2>\n
    The following are the frequently asked questions.<\/p>\n
    What is the need to set upstream in git?<\/h3>\n
    By setting upstream in git, the local branches can track the remote branches. This makes pulling changes from the remote repository very easy.<\/p>\n
    How to keep the original and forked repo in sync?<\/h3>\n
    By setting the original repo as upstream on your local copy, you can fetch the original repo changes and push them to the forked repo to keep it in sync.<\/p>\n
    What is an upstream branch in Git?<\/strong><\/h3>\n
    When you clone a git repository, the parent or remote repository branches are called the upstream branches for the local branches.<\/p>\n
    How to check the git upstream branches?<\/h3>\n
    You can check all the upstream branches using the git branch -vv command. It will show all the upstream tracking mapped to the local branches.<\/p>\n
    If you want to clone or checkout a specific commit id, checkout my blog on git checkout specific commit id.<\/a><\/p>\n
    \n
    Ngu\u1ed3n:<\/strong> How to set Git Upstream For a Respository and a Branch \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
    Source: https:\/\/devopscube.com\/set-git-upstream-respository-branch\/<\/p>\n","protected":false},"author":1,"featured_media":899,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-898","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/898","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=898"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/898\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/899"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=898"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=898"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=898"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}