I have 2 branches in my github repository. How do I enforce a branch policy for Master branch such that any changes to it must require a code review from specific folks done ?
This is best managed by repos, not branches.
You can have one repo with the master branch, and one or several forks, from which developers can make pull request in order to request a merge to master of the original repo.
Only the "specific folks" are declared collaborators on the original repo, and can review the PRs and merge them.
Then the developers can synchronize their own fork.
Related
In our git repository we have set some rules for a branch. It needs PR to merge code and needs approval from any one code owner.
A codeowner is not able to merge his own PRs. He is able to merge other peoples PRs. There is no other setting enabled that will restrict him from merging
Codeowner file looks like this,
#codeowner1 #codeowner2 #codeowner3
The codeowner has write access in the repo
I thought that he will be able to merge his own PRs since he is a codeowner. But git doesnt even ask review to him for his own PRs.
We are using Azure DevOps, recently came across the issue when some of the commits that was stated to be completed and merged to the master branch dont show up in Repos history.
Azure master branch doesnt show the merged commits
It depends on the merge method you choose when you PR.
Azure Repos has several merge strategies, and by default, all of them are allowed. You can maintain a consistent branch history by enforcing a merge strategy for PR completion.
So, if you select the Squash merge, which is a merge option that allows you to condense the Git history of topic branches when you complete a pull request. Instead of each commit on the topic branch being added to the history of the default branch, a squash merge adds all the file changes to a single new commit on the default branch.
In this case, the commits that was stated to be completed and merged to the master branch dont show up in Repos history.
You could check the document Merge strategies and squash merge for some more details.
I want to set up a proper workflow on GitHub where junior engineers submit pull request for code review and only the lead engineer can commit to the master branch.
I'm looking for input from professionals that work in a commercial software environment. I've found the page that does the permissions easy enough. There are several options. Restrict who can push to matching branches of course. Should I check others as well?
The other approach, beside the branch permission within one repo, is the gate repo:
you are setting up a public repo where developers can commit (on master or topic branches)
you are using a private, or repo within an organisation, from which you can pull
That way, you or your organisation team control the contribution you chose to include in the master of that main repository.
I would like to give merge access to my co-workers. But, I do not want them to be able to merge their code into master (or another branch I maintain: staging). Is there any way to do that?
The easiest way is to ask them to fork the repo and make PR (pull request).
You can then inspect and/or reject any PR made to the master branch.
The GitHub branch protection doesn't prevent fast-forward pushes, to the fork is the best option.
I've done a few pull requests on GH already, but I committed to the master branch. Now I read on various places that it's a good idea to create a branch.
Are there any guidelines for branch naming? I usually work with Mercurial and give my branches the same name as their relevant bug ticket ID, but that doesn't work for this.
I've looked at a few repositories: some commit to master, some commit to fix-somebug, some commit to patch-1. I understand that this doesn't create conflicts, because pull requests are merged to master (or a different, long living branch) and the branch is then deleted, is that correct?
The idea behind a branch for a pull request is to allow for said branch to be automatically deleted once the pull request is accepted.
And since April 2013, that branch will be deleted for you:
You are then suppose to update/rebase your master from the master of the upstream repo in order to get what you developed in isolation a branch from the official repo that you have forked (since that repo has accepted your pull request)
The name of the branch should represent the development effort you are engaged in.
It is always a good practise to make commit on the git branches rather than master. You can use any name for your git branch(it doesn't allow spaces in branch names, also some special characters).