Tabs or Spaces, the age old debate that will likely never be settled! Fortunately, at the end of the day consistent formatting is more valuable than the rules we follow because consistency significantly improves readability and maintainability.
One of the drawbacks of Feature Branching is the likelihood of merge conflicts as time moves forward. Even with the best of intentions we all get busy and forget to merge our integration branch into our feature branch or vice verse. A mechanism to let us know when conflict occurs would be helpful.
Continuous Integration can help mitigate this risk by automatically merging changes in a feature branch with the integration branch and testing the result. Conflict may arise from the merge itself, or from compilation, testing and other stages of a deployment pipeline.
Add a new Build Configuration
Automatically Merge and Test Feature Branches
()s denote what to show in the TeamCity UI, ie:
refs/heads/feature_onewill show as
Automatically on agent (if supported by VCS roots)
Click "Add Build Step"
"%env.TEAMCITY_GIT_PATH%" fetch origin "%env.TEAMCITY_GIT_PATH%" checkout -b master origin/master "%env.TEAMCITY_GIT_PATH%" config --local user.email "email@example.com" "%env.TEAMCITY_GIT_PATH%" config --local user.name "Auto Merge" "%env.TEAMCITY_GIT_PATH%" merge --no-commit %teamcity.build.branch%
The script above is crude to demonstrate the process, feel free to modify it to fit your needs
Some teams like the idea of pushing if the merge succeeds and tests pass. I guess that depends on your particular team and how you work together. That said here are my thoughts:
If auto pushing is of value, here's how you can modify the above to accomplish that:
Obviously this can't mitigate all forms of conflict. As Martin Fowler points out, semantic conflict will be very difficult to detect, especially if there isn't much test coverage.
Nonetheless, checking the basics can help us catch issues faster and remind us to keep the flow of information between integration and feature branches open.