Resolving CSS and Styling Conflicts
Handle merge conflicts in CSS, SCSS, and Tailwind class lists where two branches apply different styling changes to the same elements.
Detailed Explanation
CSS Merge Conflicts
Styling conflicts arise when two branches modify the same CSS selectors, class names, or Tailwind utility classes. These conflicts can be particularly tricky because the order of CSS rules matters for specificity, and combining both versions may produce unexpected visual results.
Typical CSS Conflict
<<<<<<< HEAD
.card {
padding: 16px;
border-radius: 8px;
background-color: #f5f5f5;
}
=======
.card {
padding: 24px;
border-radius: 12px;
background-color: #ffffff;
box-shadow: 0 2px 8px rgba(0,0,0,0.1);
}
>>>>>>> feature/card-redesign
Tailwind Class Conflicts
With utility-first CSS frameworks like Tailwind, conflicts often appear in class attributes:
<<<<<<< HEAD
<div className="p-4 rounded-lg bg-gray-100">
=======
<div className="p-6 rounded-xl bg-white shadow-md">
>>>>>>> feature/card-redesign
Resolution Strategy
CSS conflicts almost always require Manual Edit because blindly accepting one side discards legitimate design changes. Review the design intent behind each branch's changes, then craft a merged version that incorporates the correct styles. Discuss with your designer or check the design system documentation when in doubt.
Avoiding CSS Conflicts
Use component-scoped styling (CSS Modules, styled-components, or Tailwind's @apply in component files) to reduce the likelihood of two branches modifying the same global stylesheet.
Use Case
Your team is redesigning a card component while another developer is adjusting spacing across the app. Both branches modify the same CSS class, and a merge conflict appears in the stylesheet.