Help
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Copilot Lvl 2
Message 1 of 2

Compare 2 branches

How to ensure that any pull request coming to RELEASE branch has code cherry picked from develop branch only and not from any feature branches? To elaborate, whenever a fix is supposed to go to RELEASE branch, developer creates a release-fix branch off of RELEASE branch, then he/she has to cherry pick code from develop in to the release-fix branch and then raise a pull request from the release-fix to RELEASE branch. So basically the fix has to be pushed to develop first which is then cherry picked in to the release-fix branch. How to ensure that the code that is in release-fix branch came from develop and not from any other feature branches? Rather than verbal advice, is there a way to enforce this at git hub or in Jenkins?

1 Reply
Community Manager
Message 2 of 2

Re: Compare 2 branches

If you're using the `git cherry-pick` command, there isn't a good way to do what you're asking. This is because `git cherry-pick` creates new commit objects that contain the same changes as the original commits, but otherwise they're unrelated to the original.

 

It sounds like what you're doing is something like this:

 

  1. There is a `release` branch that contains the code that is certified for release
  2. When a change is being evaluated for release, a `release-fix-xxxx` branch is created with only that change
  3. There is a `develop` branch where multiple changes are developed in conjunction

 

This kind of setup would force the workflow that it sounds to me like you're describing. However, if you changed the setup a bit to something like this:

 

  1. There is a `release` branch that contains the code that is certified for release
  2. When someone works on a change, they create a `feature-xxxx` branch containing only that change
  3. When the change is ready for release evaluation, the branch could be evaluated as-is (or you could rename the branch to `release-fix-xxxx` if you want to signify that it is ready)

 

Then you wouldn't need to use the cherry-pick command and the requirement that things go to develop first wouldn't be necessary either. If you really want to keep a hold of the develop branch (maybe there's some important QA step that happens there), then you could use a setup like this:

 

  1. There is a `release` branch that contains the code that is certified for release
  2. There is a `develop` branch that contains the code that is in the process of being developed or being certified for release
  3. When a change is being worked on, then a `develop-xxxx` branch is created for that change only
  4. When the change is ready for evaluation, it is merged into the `develop` branch
  5. When a batch of changes has been evaluated and certified to be ready for release, then the `develop` branch is merged into the `release` branch

 

The two options I mention above are more common solutions to standard development workflows. `git cherry-pick` is almost never used in the standard flow of changes through a development process. It's used for "jumping the line", like when an important change needs to be taken from development straight to release without the standard certification steps.

 

To answer your original question though, you can use branch protections to prevent anyone but approved people from merging into specific branches. But it restricts merges based on the destination of the merge, not the source.

 

I hope that helps!