咨询适用于HTML邮件模板项目的最优Git工作流

Great question! For your use case—preserving original email templates while letting developers build and submit new variations to the same repo—a mix of protected main branches, structured folder organization, and either feature branching or forking is perfect. Let’s break down the most practical setup:

1. Lock Down the Original Template Source #

First, treat your main (or master) branch as the single source of truth for unmodified, official templates.

• Create a dedicated directory structure to separate originals from variations, like:

  templates/
    original/          # Only official, unmodified templates live here
      welcome-email/
      password-reset/
      invoice-reminder/
    variations/        # All custom versions go here
      welcome-email-client-a/
      password-reset-french/
  

• Enable branch protection on main: Restrict direct pushes, require PR reviews, and enforce that only maintainers can merge changes. This guarantees your original templates never get overwritten accidentally.

2. Feature Branch Workflow for Internal Teams #

For in-house developers, use feature branches to build new variations without touching the original templates:

• Start by pulling the latest main branch:

  git checkout main
  git pull origin main
  

• Create a new feature branch named clearly (e.g., feature/welcome-email-client-a or variation/password-reset-french):

  git checkout -b feature/welcome-email-client-a
  

• Copy the original template you’re modifying into the variations directory (never edit files in original/):

  cp -r templates/original/welcome-email templates/variations/welcome-email-client-a
  

• Make your customizations in the new variation folder, commit changes, and push the branch to the repo.
• Open a PR to merge your feature branch into main. Maintainers can review the variation without risking the original templates.

3. Forking Workflow for External/Independent Developers #

If you’re collaborating with external contributors or want to limit direct repo access, use a forking workflow:

• External developers fork your main repo to their own GitHub/GitLab account.
• They follow the same folder structure in their fork: copy an original template to variations/, modify it, and push to a feature branch in their fork.
• They submit a PR from their fork’s feature branch to your repo’s main branch.
• Your team reviews the PR, approves it, and merges it—keeping your original templates untouched while adding the new variation.

4. Pro Tips to Keep Things Organized #

• Add a CONTRIBUTING.md file that spells out the rules: always copy originals to variations/ before editing, branch naming conventions, and how to document changes (e.g., note which original template the variation is based on).
• Tag important template versions with Git tags (e.g., git tag template-v1.0) so you can easily roll back or reference past versions of originals.
• Use a PR template to prompt contributors to explain their variation’s purpose, changes made, and link to any relevant tickets.

内容的提问来源于stack exchange，提问作者Danny Drinkwater