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

Multi tool use
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?
git
marked as duplicate by Edward Thomson
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.
add a comment |
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?
git
marked as duplicate by Edward Thomson
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
add a comment |
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?
git
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
git
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
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
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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"
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).
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.
At this point, you can go back to the master branch and do a fast-forward merge.
$ git checkout master
$ git merge experiment
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 :)
I believe it performs a two-way merge for normal merges.
– Timothy
Dec 28 '18 at 22:32
add a comment |
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:
git pull
git pull --rebase
git pull origin
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.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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"
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).
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.
At this point, you can go back to the master branch and do a fast-forward merge.
$ git checkout master
$ git merge experiment
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 :)
I believe it performs a two-way merge for normal merges.
– Timothy
Dec 28 '18 at 22:32
add a comment |
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"
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).
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.
At this point, you can go back to the master branch and do a fast-forward merge.
$ git checkout master
$ git merge experiment
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 :)
I believe it performs a two-way merge for normal merges.
– Timothy
Dec 28 '18 at 22:32
add a comment |
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"
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).
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.
At this point, you can go back to the master branch and do a fast-forward merge.
$ git checkout master
$ git merge experiment
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 :)
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"
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).
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.
At this point, you can go back to the master branch and do a fast-forward merge.
$ git checkout master
$ git merge experiment
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 :)
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
add a comment |
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
add a comment |
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:
git pull
git pull --rebase
git pull origin
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.
add a comment |
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:
git pull
git pull --rebase
git pull origin
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.
add a comment |
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:
git pull
git pull --rebase
git pull origin
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.
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:
git pull
git pull --rebase
git pull origin
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.
answered Dec 28 '18 at 22:49
TimothyTimothy
37027
37027
add a comment |
add a comment |
78CLxH4RdBWBjF eqcv pSE5hhia5FkbNKuIDU,mOvqoWCU8pQ3EogpxHIgHSGPcdi7TNTH9o0y7pXA6Wl
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