trunk-based development simple workflow

trunk-based.md

In trunk-based development, developers typically work on small changes directly in the main branch or on short-lived feature branches. The goal is to integrate changes to the main branch as frequently as possible to avoid large merge conflicts and integration issues.

Here's the general workflow:

1. Update your local main branch with the latest changes from the remote main branch:

git checkout main
git pull origin main

2. Create a new feature branch from the updated main branch:

git checkout -b feature_branch

3. Make your changes in the feature branch and commit them:

git add .
git commit -m "Your commit message"

4. Regularly pull the latest changes from the main branch into your feature branch to stay up-to-date:

git pull origin main

5. Once your feature is complete, push your feature branch to the remote repository:

git push origin feature_branch

6. Create a pull request to merge your feature branch into the main branch.

7. After the pull request is reviewed and all tests pass, merge the pull request.

8. Delete the feature branch after it's merged.

This approach minimizes the time that the feature branch is divergent from the main branch, reducing the likelihood of merge conflicts.

While you can close the pull request and ask the developer to merge main into their branch and open a new pull request, it's not necessary to do so. The developer can resolve the merge conflicts in their existing branch and then push the changes. The existing pull request will automatically update with the new changes.

Here's the general workflow:

1. The developer should first pull the latest changes from main:

git checkout main
git pull origin main

2. Then, they should switch back to their feature branch and merge main into it:

git checkout feature_branch
git merge main

3. At this point, Git will indicate if there are any merge conflicts. The developer should resolve these conflicts manually by editing the files, staging them with git add, and then committing the changes.

4. Once all conflicts are resolved, the developer can push their changes:

git push origin feature_branch

The existing pull request on GitHub will automatically update with the new changes, and the merge conflicts should be resolved. This approach is generally more efficient and keeps the discussion and commit history of the pull request intact.