GODRIVER-3550 Update Documentation for Go Driver Branching and Merge … (#2045)

Author: prestonvasquez

docs/CONTRIBUTING.md

@@ -30,8 +30,6 @@ If any tests do not pass, or relevant tests are not included, the patch will not
 
 If you are working on a bug or feature listed in Jira, please include the ticket number prefixed with GODRIVER in the commit message and GitHub pull request title, (e.g. GODRIVER-123). For the patch commit message itself, please follow the [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/) guide.
 
-\=======
-
 ### Linting on commit
 
 The Go team uses [pre-commit](https://pre-commit.com/#installation) to lint both source and text files.
@@ -49,6 +47,125 @@ After that, the checks will run on any changed files when committing.  To manual
 pre-commit run --all-files
 ```
 
+### Merge up GitHub Action
+
+PR [#1962](https://github.com/mongodb/mongo-go-driver/pull/1962) added the "Merge up" GitHub Actions workflow to automatically roll changes from old branches into new ones. This section outlines how this process works.
+
+#### Regression
+
+If a regression is identified in an older branch, the fix should be applied directly to the latest
+release branch. Once the pull request with the fix is merged into latest, the "Merge up" GitHub Action will
+automatically create a pull request to merge these changes into the master branch. This ensures that all bug fixes are
+incorporated into the latest codebase and actively supported versions.
+
+For example, suppose we have four minor release branches: release/2.0, release/2.1, release/2.2, and release/2.3. If a
+regression is found in the release/2.1 branch, you would create a pull request to fix the issue in the latest supported
+branch, release/2.3. Once this pull request is merged, the "Merge up" GitHub Action will automatically create a pull
+request to merge the changes from release/2.3 into the master branch. Then you can proceed to release release/2.3.latest+1.
+
+```mermaid
+gitGraph
+   commit tag: "Initial main setup"
+
+   branch release/2.0
+   checkout release/2.0
+   commit tag: "Initial release/2.0"
+
+   checkout main
+   branch release/2.1
+   checkout release/2.1
+   commit tag: "Bug introduced"
+
+   checkout main
+   branch release/2.2
+   checkout release/2.2
+   commit tag: "Initial release/2.2"
+
+   checkout main
+   branch release/2.3
+   checkout release/2.3
+   commit tag: "Initial release/2.3"
+
+   checkout release/2.1
+   commit tag: "Bug found in release/2.1"
+
+   checkout release/2.3
+   commit tag: "Bug fix applied in release/2.3 (Manual PR)"
+
+   checkout main
+   merge release/2.3 tag: "Merge fix from release/2.3 into master (GitHub Actions)"
+   commit
+```
+
+If necessary, it is also possible to apply the fix to the older branch where the bug was originally found. In our example,
+once the pull request is merged into release/2.1, the "Merge up" GitHub Action will initiate a series of pull requests
+to roll the fix forward: first into release/2.2, then into release/2.3, and finally into master. This process makes sure
+that the change cascades through every intermediate supported version.
+
+```mermaid
+gitGraph
+   commit tag: "Initial main setup"
+
+   branch release/2.0
+   checkout release/2.0
+   commit tag: "Initial release/2.0"
+
+   checkout main
+   branch release/2.1
+   checkout release/2.1
+   commit tag: "Bug introduced"
+
+   checkout main
+   branch release/2.2
+   checkout release/2.2
+   commit tag: "Initial release/2.2"
+
+   checkout main
+   branch release/2.3
+   checkout release/2.3
+   commit tag: "Initial release/2.3"
+
+   checkout release/2.1
+   commit tag: "Bug fix in release/2.1 (Manual PR)"
+
+   checkout release/2.2
+   merge release/2.1 tag: "Merge fix from release/2.1 (GitHub Actions)"
+   commit
+
+   checkout release/2.3
+   merge release/2.2 tag: "Merge updates from release/2.2 (GitHub Actions)"
+   commit
+
+   checkout main
+   merge release/2.3 tag: "Merge updates from release/2.3 (GitHub Actions)"
+   commit
+```
+
+#### Pull Request Management
+
+When the "Merge up" GitHub Action is enabled, multiple merge-up pull requests (such as PR1, PR2, and PR3) can be
+automatically created at the same time for different bug fixes or features that all target, for example, the
+release/2.x branch. At first, PR1, PR2, and PR3 exist side by side—each handling separate changes. When PR1 and PR2 are
+closed, the Action automatically combines their changes into PR3. This final PR3 then contains all updates,
+allowing you to merge everything into release/2.x+1 in a single, streamlined step.
+
+```mermaid
+flowchart LR
+   A[PR1: Merge up from release/2.x] --> B[Close PR1]
+   C[PR2: Merge up from release/2.x] --> D[Close PR2]
+
+   B --> E[PR3: Consolidated Final Pull Request]
+   D --> E
+    E --> F[release/2.x+1]
+    B[Close PR1]
+   D[Close PR2]
+   E[PR3: Includes changes from both PR1 and PR2]
+```
+
+#### Evergreen Config Merge Strategy
+
+Changes to the testing workflow should persist through all releases in a major version.
+
 ### Cherry-picking between branches
 
 #### Using the GitHub App