The Workflow

A three-level hierarchy of branches is created, through which changes are promoted.
- Main: Only updated from the development branch Pull Requests. This branch always reflects the current production release that is seen by live users.
- Development: Reflects the code for the next release. Developers work in working branches, which are then pulled into this branch. All code pulled into this branch must be tested and undergo peer review as part of the PR process.
- Working branches: Individual branches created by each developer when they are working on changes and bug fixes. There are 4 basic types of branches: bug, feature, refactor, and style. For example: feature/course-review.

In this voyage we are going to work on the development branch, always make sure you create your new working branch based on the development branch. See the example below:

1. Before you create a new branch or merge a branch, ensure that you pull changes from the development branch to ensure that your local repository is up to date. On the terminal always type "git fetch" and "git pull".

2. Branch names should start with either bug, feature, refactor, or style. It has to be followed by the number of the issue, a description, and the user on GitHub who is creating the branch.

So if you are fixing a bug, your new working branch should be: "bug-issue/description/user"
So if you are adding a feature, your new working branch should be: "feature-issue/description/user"

3. Descriptors should be hyphenated:

"bug-1/fixed-all-caps/PaulaR-05"
"feature-2/giant-duck-modal/PaulaR-05"
"refactor-3/add-prop-types/PaulaR-05"
"style-4/everything-is-black/PaulaR-05"

4. Changes should be frequently pushed to the matching working branch on GitHub.
   And also, following the "commit rules" (I wrote more details in the section "What Should be in a Commit? and "Commit Subject Name Rules").

5. Once it has been unit tested, a Pull Request (PR) should be created to fold it into the development branch. It's always a good idea to require that PR's be reviewed by another member of the team. This helps to ensure that the quality of the app is maintained. Remember to always compare your working branch against the development branch!

6. Delete your branch from the upstream repository after it's reviewed and merged unless there is a specific reason not to.

What Should be in a Commit?

• Each commit should be a single logical change. Don't make several logical changes in one commit. For example, if a patch fixes a bug and optimizes the performance of a feature, split it into two separate commits.
• Don't split a single logical change into several commits. For example, the implementation of a feature and the corresponding tests should be in the same commit.
• Commit early and often. Small, self-contained commits are easier to understand and revert when something goes wrong.
• Commits should be ordered logically. For example, if commit B depends on changes done in commit A, then commit A should come before commit B.
• Test before you push. Do not push work that is half-complete.

Commit Subject Name Rules

1. Limit the subject line to 50 characters.
2. Capitalize the subject line.
3. Separate the subject name from commit description (if any).
4. Do not end the subject line with a period.
5. Use the imperative mode in the subject line. In other words, name it as if giving a command or instruction. A few other examples: "Clean your room", "Close the door".
6. When committing to fix an issue brought up in a PR, refer to the PR # like so:

[PR139]Fix typo in introduction to user guide

Tip: If you’re having a hard time summarizing, you might be committing too many changes at once. Strive for atomic commits.

To remove any confusion, here’s a simple rule to get it right every time. A properly formed Git commit subject line should always be able to complete the following sentence:

If applied, this commit will [your subject line here]

For example:

• If applied, this commit will refactor subsystem X for readability
• If applied, this commit will update getting started documentation
• If applied, this commit will remove deprecated methods
• If applied, this commit will release version 1.0.0
• If applied, this commit will merge pull request #123 from user/branch

Notice how this doesn’t work for the other non-imperative forms:

• If applied, this commit will fixed bug with Y
• If applied, this commit will changing behavior of X
• If applied, this commit will more fixes for broken stuff
• If applied, this commit will sweet new API methods

Commit Body Rules

The body should be used to explain what and why vs. how. Just focus on making clear the reasons:

• why you made the change in the first place (the way things worked before the change and what was wrong with that.)
• the way they work now
• why you decided to solve it the way you did
• what side effects it might have

Git Pull Requests

To review a pull request, there is a great link provided by chingu: https://www.notion.so/Git-Pull-Requests-6eeda3f9342941ef9a06d1057f0b87a6

from v44-tier1-team-05.