Git Strategies

Git is becoming an essential part of Salesforce projects, although some projects still rely on changesets for delivery.

info

There is no silver bullet.
The article presents various strategies and approaches.
A skillful combination of these will help create the ideal Git strategy for a specific project.

Why Git is Needed

Git is necessary for projects for several reasons:

1. Version Control: Git allows tracking changes in Salesforce code and metadata. This helps restore any previous version of the code if needed and see who made changes and when.

2. Collaboration: Git simplifies collaboration among multiple developers on a single project. Each developer can work on their own branch without interfering with others. Changes can then be merged into the main branch.

3. Code Reviews: Using Git makes organizing and conducting code reviews easy. This helps improve code quality and identify errors at early stages.

4. Deployment Automation: Integrating Git with CI/CD (Continuous Integration / Continuous Deployment) tools automates the deployment and testing process of changes in Salesforce, speeding up the release of new versions and reducing the likelihood of errors.

5. Security and Backup: Storing code in Git ensures its preservation and availability. Even if a local copy of the code is lost, data can always be restored from the repository.

6. Traceability: Git provides the ability to trace change history, understand the reasons and context for changes, which is especially useful for debugging and problem analysis.

7. Working with Multiple Environments: Salesforce projects often use different environments (Dev, Int, UAT, Prod, etc.). Git helps distribute code across these environments according to the release strategy.

8. Integration with Other Tools: Git easily integrates with various project management tools like Jira, Trello, and others, making project management more convenient and structured.

Why Git Strategies are Needed

An experienced manager entrusted with working with Git should understand Git strategies. An incorrectly chosen Git strategy can lead to several issues such as disruption of production, poor development quality, conflicts between developers, and project failure.

When choosing a Git strategy for a project, several factors need to be considered to ensure the chosen strategy best meets the requirements and promotes efficient development. Key aspects to consider:

1. Team Size and Structure

   • Number of Developers: Large projects with many teams and developers may require more complex strategies to manage parallel work, reduce conflicts, and increase efficiency.
   • Team Experience: Less experienced teams may find it easier to work with simpler strategies.

2. Release Frequency

   • Frequent Releases: Projects with frequent releases can benefit from strategies with minimal stages from development to production.
   • Infrequent Releases: Projects with infrequent and large releases and long development cycles are better suited to strategies with additional stages of development verification or splitting development into parallel releases.

3. Type and Scale of Project

   • Small Projects can use simple strategies to avoid unnecessary bureaucracy.
   • Large and Complex Projects require thorough version control and stability, and may need more complex strategies.

4. Need to Support Multiple Versions

   • Projects that need to be maintained in multiple versions simultaneously may require a strategy that includes release and hotfix branches.

5. Integration with CI/CD

   • If the project actively uses continuous integration and deployment tools, the chosen strategy should integrate well with these processes. It's important not to overload the pipeline.

6. Workflows and Methodologies

   • Agile Development Methodologies (Agile, Scrum) may require a strategy that supports frequent and iterative changes.
   • Traditional or Waterfall Methodologies may better align with more formalized strategies.

7. Quality and Testing Requirements

   • If the project requires thorough testing and code review before integrating changes, the strategy should meet these requirements.

8. Code and Dependency Complexity

   • Projects with many dependencies and complex code may need stricter branch management and version control.

9. Need for Quick Bug Response

   • If the project requires quick response to bugs and hotfix releases, the strategy should include mechanisms for creating and integrating hotfix branches.

A Git strategy, like a release strategy, should meet the project's requirements and architecture, ensuring flexibility and reliability.

Comparison of Git Strategies

Strategy	Team Size	Release Development Cycle Length	Parallel Releases	Supporting Frequent Deployments	Level of Support for Parallel Development
Trunk-Based Development (TBD)	Small/Medium	Short	No	High	Low
Git Flow	Small/Medium	Short/Medium	No	Medium	Low/Medium
Copado Branch	Small/Medium	Short/Medium	No	High/Medium	Low/Medium
Parallel Releases	Medium/Large	Short/Medium/Long	Yes	Medium	High
Fork Strategy	Large	Medium/Long	Yes	Low	High

Git Approaches

HotFix
Feature Branch
Org Branch