...
- Choose short and descriptive names
# good $ git checkout -b oauth-migration # bad - too vague $ git checkout -b login-fix |
|---|
Identifiers from corresponding tickets in an external service (e.g. a GitHub issue) are also good candidates for use in branch names. For example:
# GitHub issue #15 $ git checkout -b issue-15 |
|---|
Use hyphens to separate words.
- When naming Feature branches common practice is to use the naming convention feature/my-feature. This allows feature specific branches to be easily identified in the repository.
- When several people are working on the same feature, it might be convenient to have personal feature branches and a team-wide feature branch. Use of a team-wide branch will require the co-operation of the project’s Maintainers/Committers to setup the branch in the main repository. Use the following naming convention:
$ git checkout -b feature/master # team-wide branch $ git checkout -b feature/maria # Maria's personal branch $ git checkout -b feature/nick # Nick's personal branch |
|---|
Merge at will the personal branches to the team-wide branch. Eventually, the team-wide branch will be merged to master.
...
EdgeX will follow will well-established conventions for creating consistent, well written Git commit messages. Just follow the seven rules below and you shouldn’t run into any problems.
The seven rules of a good Git commit message are:
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
For example:
Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code explains that). Are there side effects or other unintuitive consequences of this change? Here's the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here
If you use an issue tracker, put references to them at the bottom, like this:
Resolves: #123 See also: #456, #789 |
|---|
Ultimately, when writing a commit message, think about what you would need to know if you run across the commit in a year from now.
- If a commit A depends on commit B, the dependency should be stated in the message of commit A.
- Similarly, if commit A solves a bug introduced by commit B, it should also be stated in the message of commit A.
- If a commit is going to be squashed to another commit use the --squash and --fixup flags respectively, in order to make the intention clear.
$ git commit --squash f387cab2 |
|---|
Merging
- Do not rewrite published history. The repository's history is valuable in its own right and it is very important to be able to tell what actually happened. Altering published history is a common source of problems for anyone working on the project.
- However, there are cases where rewriting history is legitimate. These are when:
- You are the only one working on the branch and it is not being reviewed.
...
- If your branch includes more than one commit, do not merge with a fast-forward
# good - ensures that a merge commit is created $ git merge --no-ff my-branch # bad $ git merge my-branch |
|---|
Miscellaneous
- Be consistent. This is related to the workflow but also expands to things like commit messages, branch names and tags. Having a consistent style throughout the repository makes it easy to understand what is going on by looking at the log, a commit message etc.
- Test before you push. Do not push half-done work.
- Use annotated tags for marking releases or other important points in the history. Prefer lightweight tags for personal use, such as to bookmark commits for future reference.
- Keep your repositories at a good shape by performing maintenance tasks occasionally:
...