11

In my project, it is required to add changes to the master branch using pull requests from feature branches. Currently, the repository is configured to forbid direct pushing to master, but in the past it was allowed.

Is it possible to find commits that were pushed directly to master, without a pull request?

jthill
  • 55,082
  • 5
  • 77
  • 137
pkalinow
  • 1,619
  • 1
  • 17
  • 43

3 Answers3

2

If your pull requests are kept around you can simply check that the second parent of every merge to master is a pull request.

Github keeps pull requests as refs so you can list them with git ls-remote u://r/l refs/pull/*/head, trying to find an equivalent on Atlassian's service felt like swimming in lard so you get to figure that out yourself.

For repos that use the Github convention for publishing pull requests, something like

awk  'ARGIND==1    { prhead[$1]=1; next}
      !prhead[$3]  { print $0, "was not merged from a pull request" }' \
        <(git ls-remote u://r/l refs/pull/*/head)
        <(git rev-list --first-parent --merges master --parents)

will do it.

You can (unsurprisingly enough) push anything the repo's set up to accept, so before your restrictions were in place someone could have pushed a fast-forward. Those will show up as non-merge commits on master:

git rev-list --first-parent --no-merges master

will list every commit that was made on master and not merged.

jthill
  • 55,082
  • 5
  • 77
  • 137
0

What is the merge strategy that you are using in your project? rebase or merge strategy? Do you keep the ?

AElMehdi
  • 572
  • 4
  • 12
  • I'm not sure about it. Where can I check it? As far as I know we don't force to have merge commits, but usually (if not always) they are created. – pkalinow May 10 '19 at 08:44
  • 1
    The merge strategy can be set in two levels: in your git configuration `git config --local merge.ff only` (there are several ways of doing it, I let you check the documentation), and in your code repository (github, bitbucket...). – AElMehdi May 13 '19 at 12:25
  • Another thing! Did you think about `git branch --contains=A_GIVEN_BRANCH/COMMIT_ID`? – AElMehdi May 13 '19 at 13:34
  • In BitBucket the merge strategy is set to the default, ie. "Merge commit --no-ff". Local settings may be different for each developer. – pkalinow May 14 '19 at 08:32
  • In case of `git branch --contains=...`, I have tried it, but the problem is that for git every commit that is in the history, from the beginning to the current branch pointer, is considered as contained by the branch. Even if the commit was created before the branch started. – pkalinow May 14 '19 at 08:36
-2

This equivalent to remove all the commits from the master which belong to PRs. To remove a PR's commits from master I can tell a manual method, not very productive, but might be ok:

1) make a temporary copy from the master branch to work on

git checkout -b master-sandbox

2) find all the commit hashes of a PR (you can find them online e.g. on bitbucket PR requests and copy them)

3) Remove the commits based on hash from the master-sandbox 

git rebase -i HEAD~1000

where HEAD~1000 means the last e.g. 1000 commit, or use commit hash where you would like to make the examination from, like: git rebase -i <hash>. This will open an editor with the list of commits. Find the above collected commit hashes and remove them. The remaining commits are the ones which do not belong to the PR. Repeat it with all the PRs and the remaining commits are the directly committed ones.

gazdagergo
  • 6,187
  • 1
  • 31
  • 45
  • 2
    I don't understand how could it help me. I don't want to resolve any conflicts! – pkalinow May 10 '19 at 08:40
  • What is your case, can you pls explain a bit? Why don't you simple merge your new features, why do you need to know which are the directly committed changes? Thanks in advance. – gazdagergo May 10 '19 at 08:58
  • My case was that I was responsible for the preparation of a new release from the "master" branch. I wanted to ensure that all the changes had been approved with code review. Unfortunately, pushing directly to master has been blocked recently, but had not been forbidden earlier. – pkalinow May 14 '19 at 08:17
  • Did you use *merge commit* or *squash commit* to merge the reviewed PRs? It is another policy which earns to set up. This makes the master more transparent. – gazdagergo May 14 '19 at 11:25
  • BitBucket is configured to use merge commits. So there is some trace of merged branches in the master branch. – pkalinow May 21 '19 at 08:16
  • Well, in future, if no other consideration, use squash commit as default. In this case a merge commit will represent one PR on master, while the directed committed ones (e.g. quick fixes) remain pure commits. For your current case I created an ugly solution above... it might be better than nothing. – gazdagergo May 21 '19 at 13:20