When working with hybrid in-house staff and off-site contracting resources, I find it hard to enforce my rule of always merging with our mainline development branch before committing new code, in order to reduce the amount of merge conflicts that can occur. This practice has become instilled in our in-house development group, but is often times missed by contractors who come on and off of our projects.
To the best of my ability, I train our contracting resources, providing contribution readme files along with email reminders to get them into our house practice. Unfortunately, it doesn't work as intended.
While pull requests do a good job of identifying merge conflicts, these often go ignored by contractors. Since they work in different time zones, sometimes deadlines must be extended because I cannot reach the contractors during my work hours.
Ideal Solution
My ideal solution would be to have some kind of check, that would attempt to merge the mainline development branch into the branch being worked on before a commit makes it upstream to the remote repository. If conflicts are found, the commit is rejected from making it upstream. I'm not sure if this is a paid capability of BitBucket, or a pipeline step I can build -- I'm not very familiar with the platform.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.