diff --git a/README.md b/README.md
index 93f23c5..558a7cf 100644
--- a/README.md
+++ b/README.md
@@ -16,9 +16,9 @@
 __OS2Forms__ is a drupal based solution for creating advanced webform functionality for Danish Municipalities.
 
 Solution main repositories:
-* Drupal core incl. installatioj profile: https://github.com/OS2Forms/os2forms8
+* OS2Forms main module https://github.com/OS2Forms/os2forms
+* OS2Forms forløb main module https://github.com/OS2Forms/os2forms_forloeb
 * OS2Forms forløb profile: https://github.com/OS2Forms/os2forms_forloeb_profile
-* OS2Forms main Drupal module https://github.com/OS2Forms/os2forms
 
 <a name="license"></a>
 ## License
@@ -26,31 +26,29 @@ All OS2Forms projects are using [EUPL v1.2 License](https://opensource.org/licen
 
 <a name="testing-and-ci"></a>
 ## Testing and CI
-Every OS2Forms drupal project should have continuous integration builds are performing by [Travis CI](https://travis-ci.org).
-To improve code quality and integration possibilities there are using set of following tools:
+Every OS2Forms drupal project should have CI build performed by [Github actions](). Your project might have different sets of implmented checks.
+To improve code quality and integration possibilities there are recommended to use following tools:
  * [PHP_CodeSniffer]() with [Drupal coding standards](https://www.drupal.org/docs/develop/standards/coding-standards) and best practices defined in [Coder module](https://www.drupal.org/project/coder).
  * [ESLint](https://eslint.org/) with [Drupal ESLint rules set](https://www.drupal.org/node/1955232).
  * [Stylelint](https://stylelint.io/) with rules set defined for Drupal core.
  * [Twigcs](https://github.com/friendsoftwig/twigcs) with standard set of rules
   for twig templates.
  * [Drupal-check](https://github.com/mglaman/drupal-check) to check project
- readiness to Drupal 9 via checking of deprecated code usage.
- * @TODO [PHPUnit](https://phpunit.de/) test to check key contrib modules tests.
+ readiness to Drupal 9 via checking of deprecated code usage. (ONLY FOR FULL INSTALLATIONS)
 
-For more details about travis-ci continuous integration builds
-see `.travis-ci.yml` file in project git repository.
-
-NOTE: Some projects couldn't have its own PHPUnit test. This is a part of future
-development scope.
+For more details about github-action builds see:
+* YAML files in `.github/workflows` directory of specidif git repository,
+* `Actions` tab in github repository.
 
 <a name="git-guideline"></a>
 ## Git guideline
-Project use default approach for branch naming.
+For all projects and git repositories there is used default approach with git branching. 
+
+If you are in doubt on "What branch you should use?" or "How to create it?" See [Gitflow Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) tutorial from Atlassian.
 
 ### Bracnhes
 * `develop` - general development branch (Default).
-* `develop-2.x` - development branch for version 2.x. (if requires)
-* `master` - stable version of code.
+* `master` or `main` - stable version of code.
 
 There are no specific rules for feature branch names. However we recommend
 use [OS2Forms JIRA](https://os2web.atlassian.net/browse/OS2FORMS) or
@@ -66,21 +64,12 @@ Given a version number MAJOR.MINOR.PATCH, increment the:
 * MINOR version when you add functionality in a backwards compatible manner, and
 * PATCH version when you make backwards compatible bug fixes.
 
-#### Outdated approach
-Since OS2Forms projects are Drupal friednly, there was used drupal-friendly
-git branch/tag names like 8.x, 8.x-2.x. Please keep use it or ask about changes
-in case this names are not compatible with changes you have.
-
-For new repositories it was decided to switch back to github,
-composer way to for branch names.
-
 <a name="code-review"></a>
 ## Code review
-New changes or bugfixes in existing codebase have to be added to repository
+New features of hotfixes existing codebase have to be added to repository
 through general [code review process](https://github.com/features/code-review/).
 To request a code review, use the following process:
-1. Add Github pull request from the feature/bugfix branch to 8.x or other related dev branch.
-2. Request code review from internal department
+1. Add Github pull request from the new branch to base branch accordingly with [gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow).2. Request code review from internal department
 3. Test features with customer on test setting
 4. Fix bugs or get approval from customer
 5. Request code review from one of project contributor (other department/company).
@@ -90,7 +79,7 @@ To request a code review, use the following process:
 NOTE: There are preconditions that have to be met before accepting a pull request:
 - All requested changes have to be done
 - All discussion have to be resolved
-- Pull request should have green Travis CI build status.
+- Pull request should have green CI build status.
 
 <a name="coc"></a>
 ## Code of Conduct