My developer team is working on a big branch that aims to be merged into the develop branch in the future.
This big branch acts like a mini develop branch, so we practice the use of pull requests to update this mini develop branch (although our repository admin did not restrict directly committing into this mini develop branch).
However, we also frequently take in updates from the develop branch to the mini develop branch. The current practice (for code quality) is to just use git merge on local and git push, followed by having team members manually review the changes themselves after changes on the develop has been updated on the mini develop branch.
I was wondering whether submitting a Atlassian pull request (our team uses Atlassian) would do the same as git merge + git push but with the developers having to approve the pull request before merging on the remote. That would same me some effort having to beg team members to manually review the merge to check whether anything has gone wrong.
Related
How can I lock a github develop branch so that no one can merge PR (even if PR approved) until I unlock the branch? This is needed because I want to create a release branch, out of develop and restrict unintended merge until branch out. I went through branch protection rules and it does not serve my purpose i.e. there is no option that says lock/unlock a branch.
Explanation:
I have a develop branch and developers can create feature branches from develop branch and raise PRs, and once PRs get reviewed and get approval, developers can merge their PRs to develop. Now, I want to create a release branch from develop so I want to restrict all the developers to be able to merge their PRs to develop branch even if PRs got approved. It may take a few days to create a release branch because whatever code I have in develop branch, I want to test and by this testing time, I want to lock the develop branch, so that no one can merge their PRs into develop branch. Once testing successfully done, I will create a release branch from develop and I will then unlock the develop branch, so that, from now on developers can merge their PRs to develop branch.
You can create a branch at any time from any commit, there is no reason to lock an active branch and prevent people from working.
git checkout -b <new branch name> <commit hash>, then git push.
This functionality is not available in git itself. This can be handled by whichever server you use to manage the repo. See Managing a branch protection rule # Github. You can set rules by branch name or pattern and require a PR to merge to that branch. You should also be able to set who can merge and other rules related to branch management.
Since Oct. 2022, you actually can lock a branch:
New Branch Protections: Last Pusher and Locked Branch (Oct. 2022)
Push protection enabled.
This allows for branches to be locked, prohibiting changes.
You can lock a branch allowing you to have a maintenance window and prevent changes, or to protect a fork so it only receives changes from its upstream repository.
To use this feature in a branch protection rule, enable Lock branch.
So:
How can I lock a github develop branch so that no one can merge PR (even if PR approved) until I unlock the branch?
The documentation does include:
You can enable this setting to apply the restrictions to admins and roles with the "bypass branch protections" permission, too.
I would like to configure my github repository such that I can receive security alerts if a vulnerability is detected on any branch, not just the master branch. Does anyone know how and where to make this configuration.
The workflow we use to introduce new changes to our project is the following
Create a feature branch to develop a change
By way of pull request, merge the feature branch changes into a develop branch
Build a test instance of the application from the develop branch
Verify the change in the test instance
Cherry pick the change from the develop branch.
Deploy the production instance from master branch
in a recent change we introduced a security vulnerability and we only received a github alert when the change was cherry-picked to the master branch. Can I configure github to do security scans on all the branches, or perhaps the develop branch along with master?
It looks like my question was previously asked, and there is an answer here: github vulnerable dependencies per branch
GitHub security scans occur on the default branch of a repository.
We started using GitHub as Source control in our project recently and we are using Feature branches to work on the features. Once we are done with our development, we merge it to the develop branch using pull request.
During the merge if there are conflicts, we resolve using the web editor. But during this process all the commits done on the file with conflicts get included as a part of the feature branch.
Does anyone know how can i avoid this and make sure the feature branch stays clean?
You should only merge the feature branch into the develop branch (not the other way around). Then resolve the conflicts right there in the develop branch itself.
git checkout develop
git merge feature-branch
resolve conflicts in develop
git push
Note: If you are not too comfortable with the conflict resolution process, then best to create a 'develop-merge' branch, then merge the feature branch into it before creating a cleaner pull request for merging the new 'develop-merge' into 'develop' branch.
This way the develop branch will include all the features at the same time the feature branch won't be convoluted.
Caveat: I am fairly new to both git and GitHub.
So, in my current setup, my team uses git flow Hotfixes (usually started and finished by a graphical tool such as GitKraken or IntelliJ) to make changes that have to be merged into two branches and pushed upstream in both. So for example the flow would be:
Pull latest from master
Start hotfix
Commit changes
Merge hotfix branch into both master and develop and push both upstream
We're now looking at moving our code into GitHub and would like to start using Pull Requests, for a couple of reasons:
CI hooks to run tests and stuff
a place to put code-specific comments not directly related to the underlying "issue"
avoiding the need for everyone to constantly be pulling the latest master/develop to their local machine so that they can merge changes
But in the case of Hotfixes, I'm not sure what to do because I'm merging into two branches but it really is one "action" so manually creating two pull requests seems weird, particularly since step 4) in our current flow is a single click.
Is there a smart way of handling this? My ideal case would be that pushing the Merge button on the Pull Request would just merge into both, but that doesn't seem to be an available option.
As you mentioned, a Pull Request has only one target branch, so you won't be able to push the hotfix to both master and develop by merging one Pull Request.
I'm also surprised you mention your step #4 - merging the hotfix branch to both master and develop and push upstream - is one action. While there's a high chance the merge from hotfix to master won't run into merge conflicts, I can't say the same for the merge from hotfix to develop since it could have been worked on since the last deployment to production.
My recommendation would then be the following:
Create one PR from hotfix to master and have someone review it to validate the fix
Once it's merged into master, create another PR from hotfix to develop and see if you run into merge conflicts
If that's the case, resolve the merge conflicts so the PR ends up in a state to be merged, and have someone review the PR
If there's no merge conflicts, then have someone review the PR
An alternative solution, if you really want to go down the automated path, would be to leverage both GitHub webhooks and API.
The webhook would allow you to be notified when a PR is merged. You could inspect the payload to make sure that the base branch starts with hotfix/ and the target branch is master. You could then react to that event by using the API to create a new PR from the same hotfix branch to develop.
It will involve some development, and the effort might not be worth since creating a PR via the UI is still quite easy and quick.
Our current stash repository has a Master and Develop branch.
Anytime if a developer is working on a story a developer creates a branch and once the coding is done a pull request is raised to merge to develop.
So far it has been good but when two developers are working on different feature branches on a same Repository if a developer merges his changes to develop and other one is still working on, there are issues like merge conflicts and we don't want the two different feature branches to be released together.
I know this is not an issue but we want to avoid release multiple feature branches at a time.
Any thoughts on this on what are the best practices.
I would suggest to create tags after you have merge to "develop" branch. There is no harm if you wish to release code from "master" branch using tags as well.
Honestly speaking there aren't any hard lines drawn on how you wish to release your code from Git hosted repos?
You may like to follow this sequence
rebase the feature brnach of second dev from develop branch to get changes of dev1 and avoid merge conflicts
git checkout feature_branch2
git rebase develop
merge feature-branch2 to develop branch
git checkout develop
git merge feature_branch2
tag the version you wish to release
git checkout provide_version_you_wish_to_release
git tag tag_name
The best practice is that the 2nd developer should first rebase his feature branch from "develop" branch and then merge his changes back to "develop" branch by creating a pull request.
If you don't wish to release changes from two feature branches simultaneously, you can create tags on the "develop" branch after a merge is successful and release code using these tags.
Hope this helps!