Git Conventions

Introduction

Git is a free and open-source version control system, originally created by Linus Torvalds in 2005. Git is distributed: every developer has the full history of their code repository locally. This makes the initial clone of the repository slower, but subsequent operations such as commit, blame, diff, merge, and log dramatically faster.

On out projects, we use a simple Git workflow like that:

1. Create a branch for the changes you plan to make and give it a name, such as users/jamal/add-login-page.
2. Commit changes to your branch. People often have multiple commits for a bug fix or feature.
3. Push your branch to the remote repository.
4. Create a pull request so other people can review your changes. To incorporate feedback, you might need to make more commits and push more changes.
5. Complete your pull request and resolve any merge conflicts from changes other people made after you created your branch.

Branching guidance

Develop your features and fix bugs in user branches based off your main branch. These branches are also known as topic branches. Feature branches isolate work in progress from the completed work in the main branch. Git branches are inexpensive to create and maintain. Even small fixes and changes should have their own branch.

Use a consistent naming convention for your branches to identify the work done in the branch. You can also include other information in the branch name, such as who created the branch.

• users/username/description
• users/username/workitem
• feature/feature-name
• hotfix/description

If, by mistake, you push your code into the main branch (main, master, develop, …) you must revert this last commit to return to your initial local state. Visual Studio has this Revert command.

Pull Requests

Pull requests let you tell others about changes you’ve pushed to a branch in a repository. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

A Pull Request must be validated by at least 2 approvers, to be merged (squash merging) to the common developement branch (main, tip1, develop, … depending of the project).

Keep in mind that this is the time to discuss, improve his project comprention, improve technical knowledge, etc.

Git Naming Conventions

1. Commit as soon as possible.
   • Your solution must compile correctly.
   • At least every evening.
2. Commit only source code
   • .cs, .ts, .xaml, .html, resources, …
   • Use .gitignore file. See https://github.com/github/gitignore / VisualStudio
   • Not Nuget / NPM packages
3. Commit comment convention.
   • To speed up the reviewing process
     • Start with Fix, Add, Change
     • Maximum 80 characters
     • (Optional) Reference to the work item (#)
   • To help us to write a good release notes
   • To help the future maintainers
   • Examples:
     • "Add a new login component with help button"
     • "#2145125 - Change the login component to add a password remember link"
     • "Fix the missing password remember link"
4. Branching
   • All in lower case and singular.
   • Use dash to separate words.
   • Prefix by users/username or hotfix.
   • Examples:
     • users/jamal/add-login-page
     • users/jamal/2145126-add-password-remember-link
     • hotfix/fix-missing-password