You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To report a bug, open an issue on GitHub with the label `bug` using the available bug report issue template. Please ensure the bug has not already been reported. **If the bug is a potential security vulnerability, please report it using our [security policy](https://github.com/nginxinc/nginx-hugo-theme/blob/main/SECURITY.md).**
@@ -35,14 +41,28 @@ To suggest a feature or enhancement, please create an issue on GitHub with the l
35
41
36
42
Note: if you'd like to implement a new feature, please consider creating a [feature request issue](https://github.com/nginxinc/nginx-hugo-theme/blob/main/.github/feature_request_template.md) first to start a discussion about the feature.
37
43
38
-
39
44
## Git Guidelines
40
45
41
46
- Keep a clean, concise and meaningful git commit history on your branch (within reason), rebasing locally and squashing before submitting a PR.
42
-
- If possible and/or relevant, use the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) format when writing a commit message, so that changelogs can be automatically generated
43
-
- Follow the guidelines of writing a good commit message as described here <https://chris.beams.io/posts/git-commit/> and summarised in the next few points:
44
-
- In the subject line, use the present tense ("Add feature" not "Added feature").
45
-
- In the subject line, use the imperative mood ("Move cursor to..." not "Moves cursor to...").
46
-
- Limit the subject line to 72 characters or less.
47
-
- Reference issues and pull requests liberally after the subject line.
48
-
- Add more detailed description in the body of the git message (`git commit -a` to give you more space and time in your text editor to write a good message instead of `git commit -am`).
47
+
- Split your changes into separate, atomic commits (i.e. A commit per feature or fix, where the build, tests and the system are all functioning).
48
+
- Make sure your commits are rebased on the `main` branch.
49
+
- Wrap your commit messages at 72 characters.
50
+
- The first line of the commit message is the subject line, and must have the format "Category: Brief description of what's being changed".
51
+
- The category should reflect the part of the Hugo theme you're working on, such as `Layouts`, `Styles`, `Templates`, `Assets`, `Config`, or `Docs`.
52
+
-**Examples:**
53
+
-`Layouts: Fix navigation menu rendering issue`
54
+
-`Styles: Update typography for post headings`
55
+
-`Templates: Add archive page template`
56
+
-`Assets: Optimize images and minify JS files`
57
+
-`Config: Fix site URL for production builds`
58
+
59
+
- Avoid generic categories like "`Theme`" or "`Misc`" unless the change truly applies across the entire project and can't be narrowed down further.
60
+
61
+
- You may combine categories with `+` if multiple areas are affected.
62
+
- Example: `Layouts+Styles: Add dark mode toggle styles and layout`
63
+
- Write the commit message subject line in the imperative mood ("Foo: Change the way dates work", not "Foo: Changed the way dates work").
64
+
- Write your commit messages in proper English, with care and punctuation.
65
+
- Amend your existing commits when adding changes after a review, where relevant.
66
+
- Mark each review comment as "resolved" after pushing a fix with the requested changes.
67
+
- Add your personal copyright line to files when making substantive changes. (Optional but encouraged!)
68
+
- Check the spelling of your code, comments and commit messages.
0 commit comments