Git workflow

When multiple developers works on a project, it's important to agree on how to work with branches in Git.

Repositories

Be consistent with how you name your repositories. We prefer to use lowercase kebab-case and suffix with type of repo. Example cool-project-site and cool-project-app.

Commits

Commit often and push those to a remote git repository as often as possible. You do not want any code changes go missing if a hard drive or computer stops working. Write a easy to understand commit message and try to keep files with common functionality updates grouped per commit.

GitHub flow

Start with a main branch. This is the branch that you would deploy to production. Also, it's this branch you always will start from when starting a new branch. Never commit/merge non-working code to this branch.

Branches

When starting a new feature/fix/chore, you will create a new branch from main. To better understand what kind of code update is being done, prefix the branch name with feature (when a new feature is added), fix (if it's a bug fix) or chore (if it's a maintenance update). Example feature/add-contact-form or chore/update-laravel.

During work, it's always OK to merge the main branch in to your working branch if other have made updates.

Try to keep your updates small, as soon as your change is working, try to getting it merged to main and continue your next updates in a new branch.

Pull request

To merge your code back in to main branch you will create a pull request. You can create your pull request at the same time your branch is created. The pull request page at GitHub is a great place to follow up on what you have changed and to document your changes.

Make sure that all checks in your pull request checks before asking for a code review.

Code review

When you are done with your pull request (changes is documented in the description and all code changes are done) ask a fellow developer or designer to review your code. If you have added information about the changes and maybe even a link to test the code then time is often saved for the reviewer.

When approved, merge your pull request in to main.

Staging

Sometimes you might want to test your code or share on a staging server. If the deployment is set up to be able to deploy any branch, then you are able to deploy your specific branch for testing. In this case, also add a link to your pull request description.

If the project only have one staging server, then create (if not already created) a stage branch that is deployed to the staging server. When you want to test your branch, just merge it in to the stage branch and deploy. Notice that there might be multiple branches being worked on that are merged in to stage. You should never commit any changes direct to the stage branch (only if there is a merge conflict). The stage branch should at any time be able to be overwritten by the main branch without losing any code.

Git Flow

For some projects it might be a better idea to use Git Flow. Generally for larger projects when it's important of to keep track of releases.

There are some difference comparing to "Itiden GitHub flow". You would always start in the develop branch and branch out. Any features are put in feature/your-feature-name branches and before merging to main you would create a release/vX.X.X branch.