what is the difference between git pull --rebase and git pull origin? is both commands functionality is same?...

Multi tool use
Multi tool use












-1
















This question already has an answer here:




  • When should I use git pull --rebase?

    8 answers




What is the difference between git pull --rebase and git pull origin. As per my understanding, basically git pull --rebase will update my local repo and update the branches whereas git pull origin will also update the local repo, so what is the difference between both commands?










share|improve this question















marked as duplicate by Edward Thomson git
Users with the  git badge can single-handedly close git questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Jan 1 at 19:00


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.











  • 1





    title should read git pull origin. But git pull updates your local repo with changes from the remote (origin). With rebase, your changes are added on top of changes pulled from the remote. In doing so, hopefully maintains a clean tree.

    – kirikoumath
    Dec 28 '18 at 21:26


















-1
















This question already has an answer here:




  • When should I use git pull --rebase?

    8 answers




What is the difference between git pull --rebase and git pull origin. As per my understanding, basically git pull --rebase will update my local repo and update the branches whereas git pull origin will also update the local repo, so what is the difference between both commands?










share|improve this question















marked as duplicate by Edward Thomson git
Users with the  git badge can single-handedly close git questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Jan 1 at 19:00


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.











  • 1





    title should read git pull origin. But git pull updates your local repo with changes from the remote (origin). With rebase, your changes are added on top of changes pulled from the remote. In doing so, hopefully maintains a clean tree.

    – kirikoumath
    Dec 28 '18 at 21:26
















-1












-1








-1









This question already has an answer here:




  • When should I use git pull --rebase?

    8 answers




What is the difference between git pull --rebase and git pull origin. As per my understanding, basically git pull --rebase will update my local repo and update the branches whereas git pull origin will also update the local repo, so what is the difference between both commands?










share|improve this question

















This question already has an answer here:




  • When should I use git pull --rebase?

    8 answers




What is the difference between git pull --rebase and git pull origin. As per my understanding, basically git pull --rebase will update my local repo and update the branches whereas git pull origin will also update the local repo, so what is the difference between both commands?





This question already has an answer here:




  • When should I use git pull --rebase?

    8 answers








git






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 1 at 18:19









Raedwald

26k2295157




26k2295157










asked Dec 28 '18 at 21:23









k5656k5656

407




407




marked as duplicate by Edward Thomson git
Users with the  git badge can single-handedly close git questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Jan 1 at 19:00


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.






marked as duplicate by Edward Thomson git
Users with the  git badge can single-handedly close git questions as duplicates and reopen them as needed.

StackExchange.ready(function() {
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function() {
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function() {
$hover.showInfoMessage('', {
messageElement: $msg.clone().show(),
transient: false,
position: { my: 'bottom left', at: 'top center', offsetTop: -7 },
dismissable: false,
relativeToBody: true
});
},
function() {
StackExchange.helpers.removeMessages();
}
);
});
});
Jan 1 at 19:00


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.










  • 1





    title should read git pull origin. But git pull updates your local repo with changes from the remote (origin). With rebase, your changes are added on top of changes pulled from the remote. In doing so, hopefully maintains a clean tree.

    – kirikoumath
    Dec 28 '18 at 21:26
















  • 1





    title should read git pull origin. But git pull updates your local repo with changes from the remote (origin). With rebase, your changes are added on top of changes pulled from the remote. In doing so, hopefully maintains a clean tree.

    – kirikoumath
    Dec 28 '18 at 21:26










1




1





title should read git pull origin. But git pull updates your local repo with changes from the remote (origin). With rebase, your changes are added on top of changes pulled from the remote. In doing so, hopefully maintains a clean tree.

– kirikoumath
Dec 28 '18 at 21:26







title should read git pull origin. But git pull updates your local repo with changes from the remote (origin). With rebase, your changes are added on top of changes pulled from the remote. In doing so, hopefully maintains a clean tree.

– kirikoumath
Dec 28 '18 at 21:26














2 Answers
2






active

oldest

votes


















2














Short answer:
Git pull origin performs a fetch and merges the fetched data with a merge command.
git pull --rebase performs a fetch and merges the fetched data with a rebase command.



Longer explaining answer:
Lets say you have the following local history with some commits and two branches "master" and "experiment"



Simple divergent history



There are two ways to move changes from experiment to the master branch. The first method is the merge command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit).



Merging to integrate diverged work history



Method number two: you can take the patch of the change that was introduced in C4 and
reapply it on top of C3. This is called rebasing. With the rebase command, you can take all the changes that were committed on one branch and replay them on another one.



In this example, you’d run the following:



$ git checkout experiment
$ git rebase master


It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.



Rebasing the change introduced in C4 onto C3



At this point, you can go back to the master branch and do a fast-forward merge.



$ git checkout master
$ git merge experiment


Fast-forwarding the master branch



There is no difference in the end product of the integration, but rebasing makes for
a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.



Note:
Do not rebase commits that exist outside your repository.



If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.
Things will easily get messy in collaborating environments if this guideline is not followed.



Hope this helps :)






share|improve this answer


























  • I believe it performs a two-way merge for normal merges.

    – Timothy
    Dec 28 '18 at 22:32



















0














See the official docs for an authoritative reference.



For your specific question:
origin here is the name of the remote repository you're pulling from, e.g. https://github.com/atom/atom.git. If this value is ommitted, it uses the information from the current branch (which is usually origin, since many developers only use one remote). The following are all valid commands:




  1. git pull

  2. git pull --rebase

  3. git pull origin

  4. git pull --rebase origin


The only difference is that the last two specify which remote repository they want to read their data from.
Thus, the comparison here is mainly between git pull and git pull --rebase, which hatati's answer or the official docs explain well. The docs for --rebase:




When true, rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the upstream branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes.







share|improve this answer






























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    2














    Short answer:
    Git pull origin performs a fetch and merges the fetched data with a merge command.
    git pull --rebase performs a fetch and merges the fetched data with a rebase command.



    Longer explaining answer:
    Lets say you have the following local history with some commits and two branches "master" and "experiment"



    Simple divergent history



    There are two ways to move changes from experiment to the master branch. The first method is the merge command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit).



    Merging to integrate diverged work history



    Method number two: you can take the patch of the change that was introduced in C4 and
    reapply it on top of C3. This is called rebasing. With the rebase command, you can take all the changes that were committed on one branch and replay them on another one.



    In this example, you’d run the following:



    $ git checkout experiment
    $ git rebase master


    It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.



    Rebasing the change introduced in C4 onto C3



    At this point, you can go back to the master branch and do a fast-forward merge.



    $ git checkout master
    $ git merge experiment


    Fast-forwarding the master branch



    There is no difference in the end product of the integration, but rebasing makes for
    a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.



    Note:
    Do not rebase commits that exist outside your repository.



    If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.
    Things will easily get messy in collaborating environments if this guideline is not followed.



    Hope this helps :)






    share|improve this answer


























    • I believe it performs a two-way merge for normal merges.

      – Timothy
      Dec 28 '18 at 22:32
















    2














    Short answer:
    Git pull origin performs a fetch and merges the fetched data with a merge command.
    git pull --rebase performs a fetch and merges the fetched data with a rebase command.



    Longer explaining answer:
    Lets say you have the following local history with some commits and two branches "master" and "experiment"



    Simple divergent history



    There are two ways to move changes from experiment to the master branch. The first method is the merge command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit).



    Merging to integrate diverged work history



    Method number two: you can take the patch of the change that was introduced in C4 and
    reapply it on top of C3. This is called rebasing. With the rebase command, you can take all the changes that were committed on one branch and replay them on another one.



    In this example, you’d run the following:



    $ git checkout experiment
    $ git rebase master


    It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.



    Rebasing the change introduced in C4 onto C3



    At this point, you can go back to the master branch and do a fast-forward merge.



    $ git checkout master
    $ git merge experiment


    Fast-forwarding the master branch



    There is no difference in the end product of the integration, but rebasing makes for
    a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.



    Note:
    Do not rebase commits that exist outside your repository.



    If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.
    Things will easily get messy in collaborating environments if this guideline is not followed.



    Hope this helps :)






    share|improve this answer


























    • I believe it performs a two-way merge for normal merges.

      – Timothy
      Dec 28 '18 at 22:32














    2












    2








    2







    Short answer:
    Git pull origin performs a fetch and merges the fetched data with a merge command.
    git pull --rebase performs a fetch and merges the fetched data with a rebase command.



    Longer explaining answer:
    Lets say you have the following local history with some commits and two branches "master" and "experiment"



    Simple divergent history



    There are two ways to move changes from experiment to the master branch. The first method is the merge command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit).



    Merging to integrate diverged work history



    Method number two: you can take the patch of the change that was introduced in C4 and
    reapply it on top of C3. This is called rebasing. With the rebase command, you can take all the changes that were committed on one branch and replay them on another one.



    In this example, you’d run the following:



    $ git checkout experiment
    $ git rebase master


    It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.



    Rebasing the change introduced in C4 onto C3



    At this point, you can go back to the master branch and do a fast-forward merge.



    $ git checkout master
    $ git merge experiment


    Fast-forwarding the master branch



    There is no difference in the end product of the integration, but rebasing makes for
    a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.



    Note:
    Do not rebase commits that exist outside your repository.



    If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.
    Things will easily get messy in collaborating environments if this guideline is not followed.



    Hope this helps :)






    share|improve this answer















    Short answer:
    Git pull origin performs a fetch and merges the fetched data with a merge command.
    git pull --rebase performs a fetch and merges the fetched data with a rebase command.



    Longer explaining answer:
    Lets say you have the following local history with some commits and two branches "master" and "experiment"



    Simple divergent history



    There are two ways to move changes from experiment to the master branch. The first method is the merge command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit).



    Merging to integrate diverged work history



    Method number two: you can take the patch of the change that was introduced in C4 and
    reapply it on top of C3. This is called rebasing. With the rebase command, you can take all the changes that were committed on one branch and replay them on another one.



    In this example, you’d run the following:



    $ git checkout experiment
    $ git rebase master


    It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.



    Rebasing the change introduced in C4 onto C3



    At this point, you can go back to the master branch and do a fast-forward merge.



    $ git checkout master
    $ git merge experiment


    Fast-forwarding the master branch



    There is no difference in the end product of the integration, but rebasing makes for
    a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.



    Note:
    Do not rebase commits that exist outside your repository.



    If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.
    Things will easily get messy in collaborating environments if this guideline is not followed.



    Hope this helps :)







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Dec 28 '18 at 22:41

























    answered Dec 28 '18 at 22:27









    hatatihatati

    915




    915













    • I believe it performs a two-way merge for normal merges.

      – Timothy
      Dec 28 '18 at 22:32



















    • I believe it performs a two-way merge for normal merges.

      – Timothy
      Dec 28 '18 at 22:32

















    I believe it performs a two-way merge for normal merges.

    – Timothy
    Dec 28 '18 at 22:32





    I believe it performs a two-way merge for normal merges.

    – Timothy
    Dec 28 '18 at 22:32













    0














    See the official docs for an authoritative reference.



    For your specific question:
    origin here is the name of the remote repository you're pulling from, e.g. https://github.com/atom/atom.git. If this value is ommitted, it uses the information from the current branch (which is usually origin, since many developers only use one remote). The following are all valid commands:




    1. git pull

    2. git pull --rebase

    3. git pull origin

    4. git pull --rebase origin


    The only difference is that the last two specify which remote repository they want to read their data from.
    Thus, the comparison here is mainly between git pull and git pull --rebase, which hatati's answer or the official docs explain well. The docs for --rebase:




    When true, rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the upstream branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes.







    share|improve this answer




























      0














      See the official docs for an authoritative reference.



      For your specific question:
      origin here is the name of the remote repository you're pulling from, e.g. https://github.com/atom/atom.git. If this value is ommitted, it uses the information from the current branch (which is usually origin, since many developers only use one remote). The following are all valid commands:




      1. git pull

      2. git pull --rebase

      3. git pull origin

      4. git pull --rebase origin


      The only difference is that the last two specify which remote repository they want to read their data from.
      Thus, the comparison here is mainly between git pull and git pull --rebase, which hatati's answer or the official docs explain well. The docs for --rebase:




      When true, rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the upstream branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes.







      share|improve this answer


























        0












        0








        0







        See the official docs for an authoritative reference.



        For your specific question:
        origin here is the name of the remote repository you're pulling from, e.g. https://github.com/atom/atom.git. If this value is ommitted, it uses the information from the current branch (which is usually origin, since many developers only use one remote). The following are all valid commands:




        1. git pull

        2. git pull --rebase

        3. git pull origin

        4. git pull --rebase origin


        The only difference is that the last two specify which remote repository they want to read their data from.
        Thus, the comparison here is mainly between git pull and git pull --rebase, which hatati's answer or the official docs explain well. The docs for --rebase:




        When true, rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the upstream branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes.







        share|improve this answer













        See the official docs for an authoritative reference.



        For your specific question:
        origin here is the name of the remote repository you're pulling from, e.g. https://github.com/atom/atom.git. If this value is ommitted, it uses the information from the current branch (which is usually origin, since many developers only use one remote). The following are all valid commands:




        1. git pull

        2. git pull --rebase

        3. git pull origin

        4. git pull --rebase origin


        The only difference is that the last two specify which remote repository they want to read their data from.
        Thus, the comparison here is mainly between git pull and git pull --rebase, which hatati's answer or the official docs explain well. The docs for --rebase:




        When true, rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the upstream branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes.








        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 28 '18 at 22:49









        TimothyTimothy

        37027




        37027















            78CLxH4RdBWBjF eqcv pSE5hhia5FkbNKuIDU,mOvqoWCU8pQ3EogpxHIgHSGPcdi7TNTH9o0y7pXA6Wl
            H,mMA6AbI2eglGfuqh,N8Qv,BhL2UiHt7,2PrBwWrqcCkJxH6,ttXzqoc

            Popular posts from this blog

            Monofisismo

            Angular Downloading a file using contenturl with Basic Authentication

            Olmecas