Doc: Update doc with some common uses cases.

Use cases with conflicts are out if this documentation.

README.md

@@ -1,6 +1,13 @@
 This repository defines the process and tools to work on a project that is kept
 up-to-date with a remote (so-called upstream) repository.
 
+When working with open-source projects, new features can be needed
+before reaching upstream. Using plugins or hooks to add features is
+generally recommended without having to fork. However, sometimes this
+is not possible (bugfix, core features...). The process defined here
+helps maintain a fork where managing pending contributions upstream will
+be simple.
+
 ## The workflow
 
 The workflow consists of a set of features where each feature is built on top of
@@ -53,8 +60,8 @@ gitGraph TB:
   commit
 ```
 
-The process of generating the final branch will still be the rebasing against all feature
-branches, but feature1 is marked as "merging" in the file.
+The process of generating the final target branch will still be the rebasing against all 
+feature branches, but feature1 is marked as "merging" in the file.
 
 Once all fixups, rebases, etc, of the feature branch going upstream are done, the branch
 must be integrated back with the `integrate` command. This is done on the `sync` process
@@ -128,6 +135,16 @@ and is waiting for the community to be reviewed
 
 You cannot mix these groups.
 
+
+```mermaid
+stateDiagram-v2
+    pending --> merging
+    merging --> integrated
+```
+
+Iternal reviews done before doing the contibution must be done before the pending state to be sure 
+target branch is always in a valid state. Some common use cases are described into [here](docs/workflows.md).
+
 ## Usage
 First you need to install the package
 ```

docs/workflows.md

@@ -0,0 +1,65 @@
+# Workflows for some common use cases 
+
+## 1.- Add a new feature at the end of the feature list.
+
+Manual actions to do by the dev:
+
+* Create a new branch with the feature using the last feature as base.  
+* Create a new PR with the new branch to get the review.  
+
+Manual actions to do by the review:
+
+* Validate the PR
+
+Automated actions done by GHA when the PR is approved.
+
+* Execute guw `add` command.  
+* Close PR with the feature with a comment to the guw PR merged.  
+
+## 2.- Add a new feature in the middle of the features without conflict.
+
+Similar to use case \#1, but creating the new branch with the feature using the previous feature as base. If feature `foo` is created on top of feature `bar`, checkout from `bar`.  
+
+## 3.- Remove a feature in the without a conflict
+
+* Execute the guw `remove` command to remove the features and generate a new target.
+
+## 4.- Add a new commit into a pending feature because of an internal requirement without conflict.
+
+Manual actions to do by the dev:
+
+* Create a new branch with the feature hotfix using the feature as base. If feature `foo` need to be updated, checkout a new branch `hox-hotfix1` from `foo`.  
+* Create a new PR with the new branch
+
+> [!IMPORTANT]
+> Use the base branch as prefix of the new branch is mandatory to detect that it is not a new feature
+
+Manual actions to do by the review:
+
+* Validate the PR
+
+Automated actions done by GHA when the PR is approved.
+
+* Close PR with a comment.  
+* Execute the guw `update` command to sync the features and generate a new target.
+
+## 5.- Change or delete a commit of a pending feature because of an internal requirement without conflict.
+
+Similar to use case \#3 using a fixup commit to edit a previous commit of the feature or a revert commit to delete one. The goal is to make reviewing easier while ensuring a clean Git history after the review.  
+When the PR is approved the feature needs to be rebased by squashing fixup commits (autosquash)  
+
+> [!IMPORTANT]
+> Reverted commits also must be a fixup commit
+>
+> ```
+> git revert --no-commit 1234
+> git commit --fixup 1234
+> ```
+>
+> Explanation https://stackoverflow.com/a/67739266
+
+
+# Conflicts
+
+TODO
+