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.
Related
Github has the option to allow a PR to be squashed when merged ("Squash and Merge")
Is there anyway I can configure the branch so it only allows the "Squash and Merge" option?
My scenario is this
we have a develop branch, that feature requests are pushed to
sometimes developers will forget to choose "Squash and Merge" and will commit their feature branch, with 10-20 tiny commits to the develop branch.
These changes eventually get merged to master, and feature history becomes hard to read
I have looked in hooks in branch protection rules, but didn't see any such option
Unfortunately the option to change what type of PR merge is available on Github is set on a per repo basis. Since PRs are a github thing, not a git thing, I can't think of a way that you'd be able to do anything with githooks either.
I don't see a great option for your workflow as long as you require the intermediate develop branch that eventually gets merged into master. Workflows that have multiple layers of PRs get messy on Github. The one real option would be that you require squash to merge on Github PRs and then the regular merge from develop to master happens outside a PR (could be local on a machine or via a Github action potentially).
But, your best option if this is really a big problem may be to modify your workflow. One common workflow would be that master is the development branch. Then when it is time for a release a release branch or tag, depending on your needs, is created from master. The you will have no issue turning on the repo wide requirement for squashing.
I have a scenario where I will sometimes need to cherry-pick some commits from our UAT branch into our MASTER branch. This is because the business sometimes will request that only specific "features" are moved from UAT to production. I need to be able to pick certain commits to move forward as PR.
The issue I am having is that when try to cherry pick from one the commits (from the UAT branch) to master, Azure DevOps give me the error...
"Encountered conflicts when cherry-picking commit "42af19". This operation needs to be performed locally."
I am able to do this same pattern against my UAT, QA and Integration branches, I only have this issue against our master branch. I don't have any conflicts in the source branch so I don't believe its that. I also don't have any special rules for the master branch that should keep me from doing a UI based cherry-pick.
I really can't have our developers do this locally so I am hoping for some sort of option where they can use the UI for this.
We are using ADO to host the repo for our Salesforce code. We use another system that handles the CICD pipeline.
The high-level background for this is that we have may have 2 or more PR's that have been promoted and deployed to UAT, but the business may request that we only deploy certain ones. So some PR's might remain open against master for a few dev cycles. The issue is when other PR's move through and we need to promote them from UAT to master, ALL of the changes are getting added to the UAT > MASTER PR due to the fact that the code in the PR's that are in the holding pattern have not been committed to master, so the subsequent PR's would pick up those changes and try to merge them in, and we don't want that.
The thought is that we could cherry-pick commits from UAT as a PR. These only only contain the files we actually want to deploy, not EVERYTHING.
Hopefully someone can help me out with this scenario as I am a little stuck.
Thank you all very much for your guidance!
I have been working with a similar branching strategy for Salesforce. Normally in this situation, we would do the following:
Create a branch out of master - it will be used only to resolve conflict.
git checkout -b gs-pipeline/...
Cherry-pick a commit there, you can space separate them if there are many
git cherry-pick COMMIT-HASH1 OPTIONAL-COMMIT-HASH2
Solve Conflicts manually, save files, stage them, commit and push
Open Pull Request from gs-pipeline/... -> master
Unfortunately, there is no easy way to solve this within UI as far as I am concerned.
However, when you would down merge from master -> uat(directly or via a separate branch) that may solve your issue. It should be safe as things on master/PRD should already be on UAT and all lower environments.
We have a GitHub project (master), every member of the team have a Fork of the project into their own repository.
Once a developer fixed something he create a new branch inside his local forked repo and commit that into remote repository and after that they request a Pull Request so that change go into the master reposiroty.
We publish to production "manually" once a week but we have had issues in production because accidentaly developer had committed to their forked repository and other developer with higher privilegies accept the changes and merge that into master repo, then someone else publish to production and he didnt knew that those new changes didn't passed to QA process.
So, what I want is to create like a Production Repository, so when we have the code in master repo that we know is stable and working then create like a Production branch so if by mistake something is commited and merge into master repo then the code for production publish is not affected.
Any clue or best practice to do this?
Not sure I'm understanding the question correctly, but you can add as many remote repositories as you like. There is a section in the Pro Git book called Working with Remotes that discusses this thoroughly.
In my experience, separating development and production code is typically done with a branching model such as git-flow. You can create separate repositories to solve this problem if you like, but doing so is unnecessary. This is because if developer A submits a PR that's merged by developer B, then developer C will get a non-fast-forward error when they try to commit upstream. This is called a subversion-style workflow. Per the docs:
Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
If commits to the upstream branch are not being fetched and merged appropriately before pushing, then someone has likely taken it upon themselves to rewrite history.
Your git workflow is good enough to take care of this issue.
First, to fix the issue:
Treat unintended code push as bug and fix it as you would fix any other bug. Best person to perform this activity would be the developer who pushed that code. Developer can just fix it in their fork and submit a pull request. Try not to add any other unrelated code with this pull request.
About Production Branch or Repo:
I don't think you need another Production Branch/Repo (you already have one). As it happened with your current PROD repo, accidental code push can make it to new Branch/Repo too.
Instead use tags/releases feature in GitHub. Whenever state of code in master repo is prod ready, tag it and use the tag for production publish.
We are using Gitlab (the gitlab.com free version). My colleague is creating merge requests and we are merging from one branch (development) into another (master). When my colleague merges into master the MR is shown as Merged. I am then running some tests on the merged branch (not done automatically through GL currently) and when happy with the merge I am wanting to close the merge request. However I do not have any option to close it - I do not have a close button and if I type /close in the comments it does not do anything.
Neither my colleague or myself are able to close the MRs. We both have Master status and have tried changing various MR project settings but to no avail.
PLease can anyone help?
In Gitlab, the merged status means the relevant commits have been merged and no action is needed.
A closed merge request is one that has been put aside or considered irrelevant. It is therefore not merged into the code base.
Therefore, you only merge MRs when you're happy with the changes and close them if you think the changes are not worthy of being integrated into the code base ever.
A typical workflow would be the following:
User A works on a new feature in a feature branch and pushes their work to that branch.
They can open a merge request to merge their feature branch into master.
User B pulls the feature branch, eventually rebasing it onto master, and runs the tests they want.
If User B is happy with the changes/new feature, they can merge the MR into master (or whatever branch you merge into)
The merge request will be shown as merged
Of course it's better if the tests run automatically in a CI.
With GitLab 12.2 (August 2019), you have new options which could help indicate the "closed" status of a merge request.
See "New push options for merge requests"
In GitLab 12.2, GitLab has been taught new push options to:
Set the branch to be removed when it is merged.
Change the merge request’s title.
Change the merge request’s description.
See issue and documentation
I have 2 branches - master and develop
I have been doing some pull requests in my develop branch where it contains 5 items, in which it is the same as the number of items in master.
However, someone did some commits and pushed in a few more items into the master branch, and hence now it has 8 items.
As my pull request in the develop is still not yet approved/merged, whenever I tried to update my pull request, I am getting the message stating that This pull request can't be merged. You will need to resolve conflicts to be able to merge and asked me to do the following:
git fetch origin master
git checkout develop
git merge FETCH_HEAD
git commit
git push origin HEAD
And this happens after I have 'pushed' out my commits, making me confused at times. Then I realized that it is asking me to re-add and re-commit in the additional 3 new items. So does this means I must ensure that the items and contents between these 2 branches of mine should be the same as always? I have always used git pull/fetch but will there be a better way for me to make sure?
What this means is that GitHub would like to merge your PR branch into master, but it can't, because there are conflicts. As you've discussed in the question comments, the best way to deal with this (usually) is to merge your master branch into develop on the command line. That will show you the conflicts and ask you to resolve them. Once you've completed and pushed that merge, the PR will be mergeable back into master using the green button on GitHub.
You could simply merge your deploy branch into master (which I realize sounds a bit more sensible). In that case, you'd be bypassing the PR entirely. You'd have to close the PR "unmerged", and separately you'd manually push the merge commit to master.
By doing it the first way,
you make a better audit trail by merging to master on GitHub, using the PR;
you give your team a chance to review your code after the merge, before it lands on master; and
if you have automatic tests (such as Travis CI or CircleCI) which check PRs, you give them a chance to run your merged code as well.