Mixing
How can I see when Github commits are from a pull-request/merge instead of direct commits?
We prefer a feature-branch workflow with GitHub (like the github workflow mainly). One of my roles is checking this is being done neatly but when I look at https://github.com/<our-org>/<repo>/commits/master I don't see anything demarcating when a commit is directly on the repo Vs when a PR is reviewed and accepted.
I definitely don't see a way to link commits to PRs or similar. Is this possible/easy and am I just missing it on the web UI?
github
asked Jan 2 at 19:00
Mr. BoyMr. Boy
22.4k70245461
add a comment |
We prefer a feature-branch workflow with GitHub (like the github workflow mainly). One of my roles is checking this is being done neatly but when I look at https://github.com/<our-org>/<repo>/commits/master I don't see anything demarcating when a commit is directly on the repo Vs when a PR is reviewed and accepted.
I definitely don't see a way to link commits to PRs or similar. Is this possible/easy and am I just missing it on the web UI?
github
asked Jan 2 at 19:00
Mr. BoyMr. Boy
22.4k70245461
Shouldn't this process be done as part of the review process before the PR is merged?
– Schwern
Jan 2 at 19:13
Could you post a screenshot for better understanding. Thanks!
– Arcot Deepika
Jan 2 at 19:21
@Schwern probably but sometimes we want to check that person is following the process too.
– Mr. Boy
Jan 3 at 9:23
add a comment |
We prefer a feature-branch workflow with GitHub (like the github workflow mainly). One of my roles is checking this is being done neatly but when I look at https://github.com/<our-org>/<repo>/commits/master I don't see anything demarcating when a commit is directly on the repo Vs when a PR is reviewed and accepted.
I definitely don't see a way to link commits to PRs or similar. Is this possible/easy and am I just missing it on the web UI?
github
asked Jan 2 at 19:00
Mr. BoyMr. Boy
22.4k70245461
We prefer a feature-branch workflow with GitHub (like the github workflow mainly). One of my roles is checking this is being done neatly but when I look at https://github.com/<our-org>/<repo>/commits/master I don't see anything demarcating when a commit is directly on the repo Vs when a PR is reviewed and accepted.
I definitely don't see a way to link commits to PRs or similar. Is this possible/easy and am I just missing it on the web UI?
github
github
asked Jan 2 at 19:00
Mr. BoyMr. Boy
22.4k70245461
asked Jan 2 at 19:00
Mr. BoyMr. Boy
22.4k70245461
asked Jan 2 at 19:00
Mr. BoyMr. Boy
22.4k70245461
asked Jan 2 at 19:00
Mr. BoyMr. Boy
22.4k70245461
asked Jan 2 at 19:00
Mr. BoyMr. Boy
22.4k70245461
22.4k70245461
Shouldn't this process be done as part of the review process before the PR is merged?
– Schwern
Jan 2 at 19:13
Could you post a screenshot for better understanding. Thanks!
– Arcot Deepika
Jan 2 at 19:21
@Schwern probably but sometimes we want to check that person is following the process too.
– Mr. Boy
Jan 3 at 9:23
add a comment |
Shouldn't this process be done as part of the review process before the PR is merged?
– Schwern
Jan 2 at 19:13
Could you post a screenshot for better understanding. Thanks!
– Arcot Deepika
Jan 2 at 19:21
@Schwern probably but sometimes we want to check that person is following the process too.
– Mr. Boy
Jan 3 at 9:23
Shouldn't this process be done as part of the review process before the PR is merged?
– Schwern
Jan 2 at 19:13
Shouldn't this process be done as part of the review process before the PR is merged?
– Schwern
Jan 2 at 19:13
Could you post a screenshot for better understanding. Thanks!
– Arcot Deepika
Jan 2 at 19:21
Could you post a screenshot for better understanding. Thanks!
– Arcot Deepika
Jan 2 at 19:21
@Schwern probably but sometimes we want to check that person is following the process too.
– Mr. Boy
Jan 3 at 9:23
@Schwern probably but sometimes we want to check that person is following the process too.
– Mr. Boy
Jan 3 at 9:23
add a comment |
1 Answer
1
active
oldest
votes
The simple answer is that you can tell Github to disallow direct pushes to master. That'll automate your job. All commits to master must come from a PR. https://help.github.com/articles/about-protected-branches/
You can also require that certain automated status checks pass before a PR can be merged like automated code review and CI.
https://help.github.com/articles/about-required-status-checks/
The more complicated answer...
There is nothing explicitly different about a PR than any other commit. But depending on how you merge your PRs and view your commits there will be plenty of clues.
git log and the Github commit history lie to you. Git history is interconnected commits with actual branches looking something like this.
A - B - F - G - H - I [master]
/
----C - D
Each letter is a commit. They're connected to each other. The repo starts at A. [master] is a "branch label" but it's really just a label pointing at commit I. We can see that C, D, and E were done as part of a branch and H is the commit that merged it into master.
All this can be seen in the history even after the branch is "deleted" because that just deletes the label. The history can still be seen if you know how to look. git log --graph --decorate --all, and various other repository viewing tools, reveal the true history.
$ git log --graph --decorate --all --oneline
* f164d0e (HEAD -> master) Merge branch 'feature'
|
| * ae7b325 feature 2
| * 562cb51 feature 1
* | 2504fb9 master 4
* | a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
We can see clearly the merge point and what commits were done in a branch. When you merge a PR Github will add more information to the message of the merge commit such as the PR # so it can be traced back to its source. This is of INVALUABLE use to people later on.
Unfortunately Github and git log (by default) make up a linear history that is neat and easy to read and wrong. This is a source of much of the confusion with Git.
$ git log --all --oneline
f164d0e (HEAD -> master) Merge branch 'feature'
2504fb9 master 4
a3e73ae master 3
ae7b325 feature 2
562cb51 feature 1
e8bd7c4 commit 2
46edb1d commit 1
Aside from the commit messages, all indication of branches and merges is lost. So be sure to look at the true history.
The other way you can lose history is in how you merge your PRs. Squash, rebase, and fast-forward merges will all lose the history for the branch.
Squash
This is the worst. It takes all the commits in the branch and smashes them into one commit. If you had a branch with carefully considered commits and messages forming a clear explanation of why each change was made, it will all be jumbled together.
Before squash
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After squash
* d6054cf (HEAD -> master) Squashed commit of the following:
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
While this might be very convenient for the person doing the merge, it's terrible for anyone later trying to figure out what was done in that branch and why.
Rebase
There are many, many good uses for rebase. Updating a feature branch, for example, is better done with a rebase to avoid a lot of unnecessary bookkeeping merges in the history. But when a branch is complete it should be merged, not rebased. Rebasing eliminates that the branch existed.
Before rebase
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After rebase
* aff85f0 (HEAD -> master) feature 2
* aa8bc45 feature 1
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
At least the individual commits are still there, but the topological evidence that they were done as a single unit as part of a branch to fix an issue are gone.
Fast Forward
Similar to a rebase, if Git doesn't need to merge, it won't. It'll just move the branch label forward. This happens if there was no work done on master since the branch was made. For example.
Before
* eb54d0d (feature) feature 2
* 218a926 feature 1
* e8bd7c4 (HEAD -> master) commit 2
* 46edb1d commit 1
After fast forward
$ git merge feature
* eb54d0d (HEAD -> master, feature) feature 2
* 218a926 feature 1
* e8bd7c4 commit 2
* 46edb1d commit 1
answered Jan 2 at 19:32
SchwernSchwern
91.1k17105239
I am aware about protecting but that only works if the people with access to the protected branch also follow the process properly :) And this is more of a curiosity once I started looking at commit logs in 2 repos, one using branches and the other not, and couldn't really tell the difference.
– Mr. Boy
Jan 3 at 9:24
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54011756%2fhow-can-i-see-when-github-commits-are-from-a-pull-request-merge-instead-of-direc%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The simple answer is that you can tell Github to disallow direct pushes to master. That'll automate your job. All commits to master must come from a PR. https://help.github.com/articles/about-protected-branches/
You can also require that certain automated status checks pass before a PR can be merged like automated code review and CI.
https://help.github.com/articles/about-required-status-checks/
The more complicated answer...
There is nothing explicitly different about a PR than any other commit. But depending on how you merge your PRs and view your commits there will be plenty of clues.
git log and the Github commit history lie to you. Git history is interconnected commits with actual branches looking something like this.
A - B - F - G - H - I [master]
/
----C - D
Each letter is a commit. They're connected to each other. The repo starts at A. [master] is a "branch label" but it's really just a label pointing at commit I. We can see that C, D, and E were done as part of a branch and H is the commit that merged it into master.
All this can be seen in the history even after the branch is "deleted" because that just deletes the label. The history can still be seen if you know how to look. git log --graph --decorate --all, and various other repository viewing tools, reveal the true history.
$ git log --graph --decorate --all --oneline
* f164d0e (HEAD -> master) Merge branch 'feature'
|
| * ae7b325 feature 2
| * 562cb51 feature 1
* | 2504fb9 master 4
* | a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
We can see clearly the merge point and what commits were done in a branch. When you merge a PR Github will add more information to the message of the merge commit such as the PR # so it can be traced back to its source. This is of INVALUABLE use to people later on.
Unfortunately Github and git log (by default) make up a linear history that is neat and easy to read and wrong. This is a source of much of the confusion with Git.
$ git log --all --oneline
f164d0e (HEAD -> master) Merge branch 'feature'
2504fb9 master 4
a3e73ae master 3
ae7b325 feature 2
562cb51 feature 1
e8bd7c4 commit 2
46edb1d commit 1
Aside from the commit messages, all indication of branches and merges is lost. So be sure to look at the true history.
The other way you can lose history is in how you merge your PRs. Squash, rebase, and fast-forward merges will all lose the history for the branch.
Squash
This is the worst. It takes all the commits in the branch and smashes them into one commit. If you had a branch with carefully considered commits and messages forming a clear explanation of why each change was made, it will all be jumbled together.
Before squash
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After squash
* d6054cf (HEAD -> master) Squashed commit of the following:
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
While this might be very convenient for the person doing the merge, it's terrible for anyone later trying to figure out what was done in that branch and why.
Rebase
There are many, many good uses for rebase. Updating a feature branch, for example, is better done with a rebase to avoid a lot of unnecessary bookkeeping merges in the history. But when a branch is complete it should be merged, not rebased. Rebasing eliminates that the branch existed.
Before rebase
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After rebase
* aff85f0 (HEAD -> master) feature 2
* aa8bc45 feature 1
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
At least the individual commits are still there, but the topological evidence that they were done as a single unit as part of a branch to fix an issue are gone.
Fast Forward
Similar to a rebase, if Git doesn't need to merge, it won't. It'll just move the branch label forward. This happens if there was no work done on master since the branch was made. For example.
Before
* eb54d0d (feature) feature 2
* 218a926 feature 1
* e8bd7c4 (HEAD -> master) commit 2
* 46edb1d commit 1
After fast forward
$ git merge feature
* eb54d0d (HEAD -> master, feature) feature 2
* 218a926 feature 1
* e8bd7c4 commit 2
* 46edb1d commit 1
answered Jan 2 at 19:32
SchwernSchwern
91.1k17105239
I am aware about protecting but that only works if the people with access to the protected branch also follow the process properly :) And this is more of a curiosity once I started looking at commit logs in 2 repos, one using branches and the other not, and couldn't really tell the difference.
– Mr. Boy
Jan 3 at 9:24
add a comment |
The simple answer is that you can tell Github to disallow direct pushes to master. That'll automate your job. All commits to master must come from a PR. https://help.github.com/articles/about-protected-branches/
You can also require that certain automated status checks pass before a PR can be merged like automated code review and CI.
https://help.github.com/articles/about-required-status-checks/
The more complicated answer...
There is nothing explicitly different about a PR than any other commit. But depending on how you merge your PRs and view your commits there will be plenty of clues.
git log and the Github commit history lie to you. Git history is interconnected commits with actual branches looking something like this.
A - B - F - G - H - I [master]
/
----C - D
Each letter is a commit. They're connected to each other. The repo starts at A. [master] is a "branch label" but it's really just a label pointing at commit I. We can see that C, D, and E were done as part of a branch and H is the commit that merged it into master.
All this can be seen in the history even after the branch is "deleted" because that just deletes the label. The history can still be seen if you know how to look. git log --graph --decorate --all, and various other repository viewing tools, reveal the true history.
$ git log --graph --decorate --all --oneline
* f164d0e (HEAD -> master) Merge branch 'feature'
|
| * ae7b325 feature 2
| * 562cb51 feature 1
* | 2504fb9 master 4
* | a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
We can see clearly the merge point and what commits were done in a branch. When you merge a PR Github will add more information to the message of the merge commit such as the PR # so it can be traced back to its source. This is of INVALUABLE use to people later on.
Unfortunately Github and git log (by default) make up a linear history that is neat and easy to read and wrong. This is a source of much of the confusion with Git.
$ git log --all --oneline
f164d0e (HEAD -> master) Merge branch 'feature'
2504fb9 master 4
a3e73ae master 3
ae7b325 feature 2
562cb51 feature 1
e8bd7c4 commit 2
46edb1d commit 1
Aside from the commit messages, all indication of branches and merges is lost. So be sure to look at the true history.
The other way you can lose history is in how you merge your PRs. Squash, rebase, and fast-forward merges will all lose the history for the branch.
Squash
This is the worst. It takes all the commits in the branch and smashes them into one commit. If you had a branch with carefully considered commits and messages forming a clear explanation of why each change was made, it will all be jumbled together.
Before squash
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After squash
* d6054cf (HEAD -> master) Squashed commit of the following:
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
While this might be very convenient for the person doing the merge, it's terrible for anyone later trying to figure out what was done in that branch and why.
Rebase
There are many, many good uses for rebase. Updating a feature branch, for example, is better done with a rebase to avoid a lot of unnecessary bookkeeping merges in the history. But when a branch is complete it should be merged, not rebased. Rebasing eliminates that the branch existed.
Before rebase
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After rebase
* aff85f0 (HEAD -> master) feature 2
* aa8bc45 feature 1
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
At least the individual commits are still there, but the topological evidence that they were done as a single unit as part of a branch to fix an issue are gone.
Fast Forward
Similar to a rebase, if Git doesn't need to merge, it won't. It'll just move the branch label forward. This happens if there was no work done on master since the branch was made. For example.
Before
* eb54d0d (feature) feature 2
* 218a926 feature 1
* e8bd7c4 (HEAD -> master) commit 2
* 46edb1d commit 1
After fast forward
$ git merge feature
* eb54d0d (HEAD -> master, feature) feature 2
* 218a926 feature 1
* e8bd7c4 commit 2
* 46edb1d commit 1
answered Jan 2 at 19:32
SchwernSchwern
91.1k17105239
I am aware about protecting but that only works if the people with access to the protected branch also follow the process properly :) And this is more of a curiosity once I started looking at commit logs in 2 repos, one using branches and the other not, and couldn't really tell the difference.
– Mr. Boy
Jan 3 at 9:24
add a comment |
The simple answer is that you can tell Github to disallow direct pushes to master. That'll automate your job. All commits to master must come from a PR. https://help.github.com/articles/about-protected-branches/
You can also require that certain automated status checks pass before a PR can be merged like automated code review and CI.
https://help.github.com/articles/about-required-status-checks/
The more complicated answer...
There is nothing explicitly different about a PR than any other commit. But depending on how you merge your PRs and view your commits there will be plenty of clues.
git log and the Github commit history lie to you. Git history is interconnected commits with actual branches looking something like this.
A - B - F - G - H - I [master]
/
----C - D
Each letter is a commit. They're connected to each other. The repo starts at A. [master] is a "branch label" but it's really just a label pointing at commit I. We can see that C, D, and E were done as part of a branch and H is the commit that merged it into master.
All this can be seen in the history even after the branch is "deleted" because that just deletes the label. The history can still be seen if you know how to look. git log --graph --decorate --all, and various other repository viewing tools, reveal the true history.
$ git log --graph --decorate --all --oneline
* f164d0e (HEAD -> master) Merge branch 'feature'
|
| * ae7b325 feature 2
| * 562cb51 feature 1
* | 2504fb9 master 4
* | a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
We can see clearly the merge point and what commits were done in a branch. When you merge a PR Github will add more information to the message of the merge commit such as the PR # so it can be traced back to its source. This is of INVALUABLE use to people later on.
Unfortunately Github and git log (by default) make up a linear history that is neat and easy to read and wrong. This is a source of much of the confusion with Git.
$ git log --all --oneline
f164d0e (HEAD -> master) Merge branch 'feature'
2504fb9 master 4
a3e73ae master 3
ae7b325 feature 2
562cb51 feature 1
e8bd7c4 commit 2
46edb1d commit 1
Aside from the commit messages, all indication of branches and merges is lost. So be sure to look at the true history.
The other way you can lose history is in how you merge your PRs. Squash, rebase, and fast-forward merges will all lose the history for the branch.
Squash
This is the worst. It takes all the commits in the branch and smashes them into one commit. If you had a branch with carefully considered commits and messages forming a clear explanation of why each change was made, it will all be jumbled together.
Before squash
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After squash
* d6054cf (HEAD -> master) Squashed commit of the following:
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
While this might be very convenient for the person doing the merge, it's terrible for anyone later trying to figure out what was done in that branch and why.
Rebase
There are many, many good uses for rebase. Updating a feature branch, for example, is better done with a rebase to avoid a lot of unnecessary bookkeeping merges in the history. But when a branch is complete it should be merged, not rebased. Rebasing eliminates that the branch existed.
Before rebase
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After rebase
* aff85f0 (HEAD -> master) feature 2
* aa8bc45 feature 1
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
At least the individual commits are still there, but the topological evidence that they were done as a single unit as part of a branch to fix an issue are gone.
Fast Forward
Similar to a rebase, if Git doesn't need to merge, it won't. It'll just move the branch label forward. This happens if there was no work done on master since the branch was made. For example.
Before
* eb54d0d (feature) feature 2
* 218a926 feature 1
* e8bd7c4 (HEAD -> master) commit 2
* 46edb1d commit 1
After fast forward
$ git merge feature
* eb54d0d (HEAD -> master, feature) feature 2
* 218a926 feature 1
* e8bd7c4 commit 2
* 46edb1d commit 1
answered Jan 2 at 19:32
SchwernSchwern
91.1k17105239
The simple answer is that you can tell Github to disallow direct pushes to master. That'll automate your job. All commits to master must come from a PR. https://help.github.com/articles/about-protected-branches/
You can also require that certain automated status checks pass before a PR can be merged like automated code review and CI.
https://help.github.com/articles/about-required-status-checks/
The more complicated answer...
There is nothing explicitly different about a PR than any other commit. But depending on how you merge your PRs and view your commits there will be plenty of clues.
git log and the Github commit history lie to you. Git history is interconnected commits with actual branches looking something like this.
A - B - F - G - H - I [master]
/
----C - D
Each letter is a commit. They're connected to each other. The repo starts at A. [master] is a "branch label" but it's really just a label pointing at commit I. We can see that C, D, and E were done as part of a branch and H is the commit that merged it into master.
All this can be seen in the history even after the branch is "deleted" because that just deletes the label. The history can still be seen if you know how to look. git log --graph --decorate --all, and various other repository viewing tools, reveal the true history.
$ git log --graph --decorate --all --oneline
* f164d0e (HEAD -> master) Merge branch 'feature'
|
| * ae7b325 feature 2
| * 562cb51 feature 1
* | 2504fb9 master 4
* | a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
We can see clearly the merge point and what commits were done in a branch. When you merge a PR Github will add more information to the message of the merge commit such as the PR # so it can be traced back to its source. This is of INVALUABLE use to people later on.
Unfortunately Github and git log (by default) make up a linear history that is neat and easy to read and wrong. This is a source of much of the confusion with Git.
$ git log --all --oneline
f164d0e (HEAD -> master) Merge branch 'feature'
2504fb9 master 4
a3e73ae master 3
ae7b325 feature 2
562cb51 feature 1
e8bd7c4 commit 2
46edb1d commit 1
Aside from the commit messages, all indication of branches and merges is lost. So be sure to look at the true history.
The other way you can lose history is in how you merge your PRs. Squash, rebase, and fast-forward merges will all lose the history for the branch.
Squash
This is the worst. It takes all the commits in the branch and smashes them into one commit. If you had a branch with carefully considered commits and messages forming a clear explanation of why each change was made, it will all be jumbled together.
Before squash
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After squash
* d6054cf (HEAD -> master) Squashed commit of the following:
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
While this might be very convenient for the person doing the merge, it's terrible for anyone later trying to figure out what was done in that branch and why.
Rebase
There are many, many good uses for rebase. Updating a feature branch, for example, is better done with a rebase to avoid a lot of unnecessary bookkeeping merges in the history. But when a branch is complete it should be merged, not rebased. Rebasing eliminates that the branch existed.
Before rebase
* eb54d0d (feature) feature 2
* 218a926 feature 1
| * 2504fb9 (HEAD -> master) master 4
| * a3e73ae master 3
|/
* e8bd7c4 commit 2
* 46edb1d commit 1
After rebase
* aff85f0 (HEAD -> master) feature 2
* aa8bc45 feature 1
* 2504fb9 master 4
* a3e73ae master 3
* e8bd7c4 commit 2
* 46edb1d commit 1
At least the individual commits are still there, but the topological evidence that they were done as a single unit as part of a branch to fix an issue are gone.
Fast Forward
Similar to a rebase, if Git doesn't need to merge, it won't. It'll just move the branch label forward. This happens if there was no work done on master since the branch was made. For example.
Before
* eb54d0d (feature) feature 2
* 218a926 feature 1
* e8bd7c4 (HEAD -> master) commit 2
* 46edb1d commit 1
After fast forward
$ git merge feature
* eb54d0d (HEAD -> master, feature) feature 2
* 218a926 feature 1
* e8bd7c4 commit 2
* 46edb1d commit 1
answered Jan 2 at 19:32
SchwernSchwern
91.1k17105239
answered Jan 2 at 19:32
SchwernSchwern
91.1k17105239
answered Jan 2 at 19:32
SchwernSchwern
91.1k17105239
answered Jan 2 at 19:32
SchwernSchwern
91.1k17105239
91.1k17105239
I am aware about protecting but that only works if the people with access to the protected branch also follow the process properly :) And this is more of a curiosity once I started looking at commit logs in 2 repos, one using branches and the other not, and couldn't really tell the difference.
– Mr. Boy
Jan 3 at 9:24
add a comment |
I am aware about protecting but that only works if the people with access to the protected branch also follow the process properly :) And this is more of a curiosity once I started looking at commit logs in 2 repos, one using branches and the other not, and couldn't really tell the difference.
– Mr. Boy
Jan 3 at 9:24
I am aware about protecting but that only works if the people with access to the protected branch also follow the process properly :) And this is more of a curiosity once I started looking at commit logs in 2 repos, one using branches and the other not, and couldn't really tell the difference.
– Mr. Boy
Jan 3 at 9:24
I am aware about protecting but that only works if the people with access to the protected branch also follow the process properly :) And this is more of a curiosity once I started looking at commit logs in 2 repos, one using branches and the other not, and couldn't really tell the difference.
– Mr. Boy
Jan 3 at 9:24
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54011756%2fhow-can-i-see-when-github-commits-are-from-a-pull-request-merge-instead-of-direc%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Shouldn't this process be done as part of the review process before the PR is merged?
– Schwern
Jan 2 at 19:13
Could you post a screenshot for better understanding. Thanks!
– Arcot Deepika
Jan 2 at 19:21
@Schwern probably but sometimes we want to check that person is following the process too.
– Mr. Boy
Jan 3 at 9:23