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
Before committing changes to a GitHub repository, it's essential to set up a GPG (GNU Privacy Guard) signing key. These keys are used to sign commits, tags, and other data in GitHub repositories, verifying their authenticity and integrity, and ensuring they haven't been tampered with. To use signing keys effectively, make sure to complete the following steps:
56
+
57
+
##### Generating a GPG key
58
+
59
+
If you haven't already done so, generate an OpenPGP keypair.
60
+
61
+
- Download and install [the GPG command line tools](https://www.gnupg.org/download/) for your operating system. We generally recommend installing the latest version for your operating system.
62
+
- Open Terminal.
63
+
- Generate a GPG key pair.
64
+
65
+
```bash
66
+
$ gpg --full-generate-key
67
+
```
68
+
69
+
- At the prompt you can specify the kind of key, size, and the length of time the key should be valid or just press `Enter` to accept the default
70
+
- Verify that your selections are correct.
71
+
- Enter your user ID information.
72
+
- Type a secure passphrase.
73
+
- Use the `gpg --list-secret-keys --keyid-format=long` command to list the long form of the GPG keys for which you have both a public and private key. A private key is required for signing commits or tags.
74
+
- From the list of GPG keys, copy the long form of the GPG key ID you'd like to use.
75
+
- Paste the text below, substituting in the GPG key ID you'd like to use. In this example, the GPG key ID is `3AA5C34371567BD2`:
76
+
77
+
```bash
78
+
$ gpg --armor --export 3AA5C34371567BD2
79
+
```
80
+
81
+
- Copy your GPG key, beginning with `-----BEGIN PGP PUBLIC KEY BLOCK-----` and ending with `-----END PGP PUBLIC KEY BLOCK-----`.
82
+
- Add the GPG key to your GitHub account.
83
+
84
+
##### Configure Git
85
+
86
+
Make sure Git is configured to use the correct signing key. You can do this by setting the `user.signingkey` configuration option in Git. Use the following command to set your signing key. In this example, the GPG key ID is `3AA5C34371567BD2`:
To sign all commits by default in any local repository on your computer, run the following command:
93
+
94
+
```bash
95
+
$ git config --global commit.gpgsign true
96
+
```
54
97
55
98
Commiting multiple files with changes on multiple resources is not allowed.
56
99
Commit message should clearly describe on which resource changes are made.
57
100
58
101
Add and commit:
59
102
60
-
```bash
61
-
$ git add my/changed/files
62
-
$ git commit
63
-
```
64
-
103
+
```bash
104
+
$ git add my/changed/files
105
+
$ git commit
106
+
```
107
+
65
108
Commit your changes in logical chunks. Please do not push all changes in one commit.
66
109
67
110
> Run `npm run fix` before commiting for not having conflict with CI linter.
68
111
69
112
Please adhere to these [Commit message guidelines](#commit-message-guidelines)
70
-
or your code is unlikely be merged into the main project.
113
+
or your code is unlikely be merged into the main project.
71
114
72
115
#### Step 4: Sync
73
116
74
117
Use git pull/merge to synchronize your work with the IF repository.
75
118
76
-
```bash
77
-
$ git pull upstream dev
78
-
```
79
-
119
+
```bash
120
+
$ git pull upstream dev
121
+
```
122
+
80
123
#### Step 5: Push
81
124
82
125
Push your topic branch to your fork:
83
126
84
-
```bash
85
-
$ git push origin <topic-branch-name>
86
-
```
127
+
```bash
128
+
$ git push origin <topic-branch-name>
129
+
```
87
130
88
131
#### Step 6: Pull Request
89
132
@@ -97,40 +140,39 @@ CI included lint checks, running tests, and etc.
97
140
98
141
The commit message should describe what changed and why.
99
142
100
-
1. The first line should:
101
-
* contain a short description of the change
102
-
* be 60 characters or less
103
-
* be prefixed with the name of the changed subsystem
104
-
* be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code,
105
-
like function/variable names
106
-
107
-
Examples:
108
-
109
-
```
110
-
util: add getInitializedModel method to models.
111
-
deps: add express package to dependencies.
112
-
service: refactor get user.
113
-
```
114
-
2. Keep the second line blank.
115
-
116
-
3. Wrap all other lines at 72 columns:
117
-
* describe each line in logical chunks
118
-
* start each line with: space hyphen space ( - ...)
119
-
* be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code,
120
-
like function/variable names
121
-
143
+
1. The first line should:
144
+
- contain a short description of the change
145
+
- be 60 characters or less
146
+
- be prefixed with the name of the changed subsystem
147
+
- be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code,
148
+
like function/variable names
122
149
Examples:
123
-
124
-
```
125
-
- remove deprecated logger
126
-
- refactor some method
127
-
- add JSDoc on existing function
128
-
```
150
+
```
151
+
util: add getInitializedModel method to models.
152
+
deps: add express package to dependencies.
153
+
service: refactor get user.
154
+
```
155
+
2. Keep the second line blank.
156
+
3. Wrap all other lines at 72 columns:
157
+
158
+
- describe each line in logical chunks
159
+
- start each line with: space hyphen space ( - ...)
160
+
- be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code,
161
+
like function/variable names
162
+
163
+
Examples:
164
+
165
+
```
166
+
- remove deprecated logger
167
+
- refactor some method
168
+
- add JSDoc on existing function
169
+
```
170
+
129
171
## Coding guidelines
130
172
131
173
#### Code structuring patterns
132
174
133
-
Avoid having functions which are responsible to do multiple things at the same time. Make sure one function/method does one thing, and does it well.
175
+
Avoid having functions which are responsible to do multiple things at the same time. Make sure one function/method does one thing, and does it well.
134
176
135
177
###### Object Oriented Programming
136
178
@@ -178,9 +220,10 @@ class MockClass {
178
220
179
221
#### Writing tests
180
222
181
-
One test file should be responsible for one module. `describe` blocks should be used for module and function/method description. First `describe` should follow `resource/module: ` pattern. Second describe title should follow `method(): ` pattern. Test units can use either `test` or `it`, title should exactly describe behaviour and input argument. Make sure each test case covers one branch.
223
+
One test file should be responsible for one module. `describe` blocks should be used for module and function/method description. First `describe` should follow `resource/module: ` pattern. Second describe title should follow `method(): ` pattern. Test units can use either `test` or `it`, title should exactly describe behaviour and input argument. Make sure each test case covers one branch.
0 commit comments