nitor 1.6.0 → 1.7.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +15 -0
- package/LICENSE +15 -0
- package/README.md +2 -2
- package/package.json +13 -4
- package/.commitlintrc.json +0 -10
- package/.editorconfig +0 -16
- package/.eslintrc.js +0 -29
- package/.gitattributes +0 -2
- package/.prettierrc +0 -5
- package/.releaserc.json +0 -34
- package/docs/AUTOCOMPLETE.md +0 -136
- package/docs/BACKUP.md +0 -343
- package/docs/BUILD.md +0 -120
- package/docs/BUILD_DEPLOY.md +0 -320
- package/docs/CLEANUP.md +0 -285
- package/docs/CREATE_BRANCH.md +0 -173
- package/docs/DEPLOY.md +0 -130
- package/docs/MERGE.md +0 -253
- package/docs/MR_STATUS.md +0 -74
- package/docs/README.md +0 -281
- package/docs/REFACTOR.md +0 -375
- package/docs/REVIEW.md +0 -185
- package/docs/TIME_ENTRY.md +0 -422
package/docs/BUILD.md
DELETED
|
@@ -1,120 +0,0 @@
|
|
|
1
|
-
# Build Command Guide
|
|
2
|
-
|
|
3
|
-
## Overview
|
|
4
|
-
|
|
5
|
-
The `build` command compiles and builds specified components of your projects. It supports building multiple projects, components, and instances.
|
|
6
|
-
|
|
7
|
-
## Usage
|
|
8
|
-
|
|
9
|
-
### Basic Syntax
|
|
10
|
-
|
|
11
|
-
```bash
|
|
12
|
-
nitor build -project <project name> -components <component name> -instance <instance name>
|
|
13
|
-
```
|
|
14
|
-
|
|
15
|
-
### Short Form
|
|
16
|
-
|
|
17
|
-
```bash
|
|
18
|
-
nitor build -p <project name> -c <component name> -i <instance name>
|
|
19
|
-
```
|
|
20
|
-
|
|
21
|
-
## Options
|
|
22
|
-
|
|
23
|
-
| Option | Short | Description | Values |
|
|
24
|
-
| -------------- | ------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
25
|
-
| `--project` | `-p` | Project name | `portal`, `gateway`, `phr`, `configService`, `healthRecords`, `centralAuth`, `mpi`, `phrAdminBackend`, `phrAdminClient`, `terminologyService` |
|
|
26
|
-
| `--components` | `-c` | Component name | `client`, `administration`, `provider`, `rest-api` |
|
|
27
|
-
| `--instance` | `-i` | Instance name | `dev`, `qa`, `pilot` |
|
|
28
|
-
| `--help` | `-help` | Show help | - |
|
|
29
|
-
|
|
30
|
-
## Examples
|
|
31
|
-
|
|
32
|
-
### Build Portal Client for Dev
|
|
33
|
-
|
|
34
|
-
```bash
|
|
35
|
-
nitor build -p portal -c client -i dev
|
|
36
|
-
```
|
|
37
|
-
|
|
38
|
-
### Build Gateway Backend for QA
|
|
39
|
-
|
|
40
|
-
```bash
|
|
41
|
-
nitor build -project gateway -components rest-api -instance qa
|
|
42
|
-
```
|
|
43
|
-
|
|
44
|
-
### Build Multiple Components
|
|
45
|
-
|
|
46
|
-
```bash
|
|
47
|
-
nitor build -p phr -c "client administration" -i pilot
|
|
48
|
-
```
|
|
49
|
-
|
|
50
|
-
## Supported Projects
|
|
51
|
-
|
|
52
|
-
- **portal** - Portal application
|
|
53
|
-
- **gateway** - Gateway service
|
|
54
|
-
- **phr** - Personal Health Records
|
|
55
|
-
- **configService** - Configuration service
|
|
56
|
-
- **healthRecords** - Health records service
|
|
57
|
-
- **centralAuth** - Central authentication service
|
|
58
|
-
- **mpi** - Master Patient Index
|
|
59
|
-
- **phrAdminBackend** - PHR admin backend
|
|
60
|
-
- **phrAdminClient** - PHR admin client
|
|
61
|
-
- **terminologyService** - Terminology service
|
|
62
|
-
|
|
63
|
-
## Supported Components
|
|
64
|
-
|
|
65
|
-
- **client** - Frontend client application
|
|
66
|
-
- **administration** - Administration panel
|
|
67
|
-
- **provider** - Provider interface
|
|
68
|
-
- **rest-api** - REST API backend
|
|
69
|
-
|
|
70
|
-
## Supported Instances
|
|
71
|
-
|
|
72
|
-
- **dev** - Development environment
|
|
73
|
-
- **qa** - Quality assurance environment
|
|
74
|
-
- **pilot** - Pilot/staging environment
|
|
75
|
-
|
|
76
|
-
## Build Process
|
|
77
|
-
|
|
78
|
-
The build command will:
|
|
79
|
-
|
|
80
|
-
1. Validate project, component, and instance parameters
|
|
81
|
-
2. Trigger the build process for specified components
|
|
82
|
-
3. Monitor build status
|
|
83
|
-
4. Report build results
|
|
84
|
-
|
|
85
|
-
## Troubleshooting
|
|
86
|
-
|
|
87
|
-
### Build Fails
|
|
88
|
-
|
|
89
|
-
1. **Check parameters:**
|
|
90
|
-
|
|
91
|
-
```bash
|
|
92
|
-
nitor build -help
|
|
93
|
-
```
|
|
94
|
-
|
|
95
|
-
2. **Verify project exists:**
|
|
96
|
-
Ensure the project name is correct and exists in the supported projects list
|
|
97
|
-
|
|
98
|
-
3. **Check build logs:**
|
|
99
|
-
Review the build output for specific error messages
|
|
100
|
-
|
|
101
|
-
### Invalid Component
|
|
102
|
-
|
|
103
|
-
If you receive an error about invalid components, verify that:
|
|
104
|
-
|
|
105
|
-
- The component name is spelled correctly
|
|
106
|
-
- The component exists for the specified project
|
|
107
|
-
- You're using the correct instance
|
|
108
|
-
|
|
109
|
-
## Getting Help
|
|
110
|
-
|
|
111
|
-
To see all available options:
|
|
112
|
-
|
|
113
|
-
```bash
|
|
114
|
-
nitor build -help
|
|
115
|
-
```
|
|
116
|
-
|
|
117
|
-
## Related Commands
|
|
118
|
-
|
|
119
|
-
- `nitor deploy` - Deploy built components
|
|
120
|
-
- `nitor build-deploy` - Build and deploy in one command
|
package/docs/BUILD_DEPLOY.md
DELETED
|
@@ -1,320 +0,0 @@
|
|
|
1
|
-
# Build-Deploy Command Guide
|
|
2
|
-
|
|
3
|
-
## Overview
|
|
4
|
-
|
|
5
|
-
The `build-deploy` command combines build and deployment operations into a single workflow. It builds specified components, monitors the build status, and automatically deploys them if the build succeeds.
|
|
6
|
-
|
|
7
|
-
## Usage
|
|
8
|
-
|
|
9
|
-
### Basic Syntax
|
|
10
|
-
|
|
11
|
-
```bash
|
|
12
|
-
nitor build-deploy -project <project name> -components <component name> -instance <instance name>
|
|
13
|
-
```
|
|
14
|
-
|
|
15
|
-
### Short Form
|
|
16
|
-
|
|
17
|
-
```bash
|
|
18
|
-
nitor build-deploy -p <project name> -c <component name> -i <instance name>
|
|
19
|
-
```
|
|
20
|
-
|
|
21
|
-
## Options
|
|
22
|
-
|
|
23
|
-
| Option | Short | Description | Values |
|
|
24
|
-
| -------------- | ------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
25
|
-
| `--project` | `-p` | Project name | `portal`, `gateway`, `phr`, `configService`, `healthRecords`, `centralAuth`, `mpi`, `phrAdminBackend`, `phrAdminClient`, `terminologyService` |
|
|
26
|
-
| `--components` | `-c` | Component name | `client`, `administration`, `provider`, `rest-api` |
|
|
27
|
-
| `--instance` | `-i` | Instance name | `dev`, `qa`, `pilot` |
|
|
28
|
-
| `--help` | `-help` | Show help | - |
|
|
29
|
-
|
|
30
|
-
## Examples
|
|
31
|
-
|
|
32
|
-
### Build and Deploy Portal Client to Dev
|
|
33
|
-
|
|
34
|
-
```bash
|
|
35
|
-
nitor build-deploy -p portal -c client -i dev
|
|
36
|
-
```
|
|
37
|
-
|
|
38
|
-
### Build and Deploy Gateway Backend to QA
|
|
39
|
-
|
|
40
|
-
```bash
|
|
41
|
-
nitor build-deploy -project gateway -components rest-api -instance qa
|
|
42
|
-
```
|
|
43
|
-
|
|
44
|
-
### Build and Deploy Multiple Components
|
|
45
|
-
|
|
46
|
-
```bash
|
|
47
|
-
nitor build-deploy -p phr -c "client administration" -i pilot
|
|
48
|
-
```
|
|
49
|
-
|
|
50
|
-
## Workflow Process
|
|
51
|
-
|
|
52
|
-
The build-deploy command executes these steps:
|
|
53
|
-
|
|
54
|
-
### 1. Build Phase
|
|
55
|
-
|
|
56
|
-
- Validates project, component, and instance parameters
|
|
57
|
-
- Triggers build process for specified components
|
|
58
|
-
- Monitors build progress
|
|
59
|
-
|
|
60
|
-
### 2. Wait Period
|
|
61
|
-
|
|
62
|
-
- Waits for build to complete (approximately 4 minutes)
|
|
63
|
-
- Monitors build status
|
|
64
|
-
- Checks for build errors
|
|
65
|
-
|
|
66
|
-
### 3. Status Check
|
|
67
|
-
|
|
68
|
-
- Verifies build completion
|
|
69
|
-
- Checks if build passed or failed
|
|
70
|
-
- Determines if deployment should proceed
|
|
71
|
-
|
|
72
|
-
### 4. Deploy Phase (if build succeeds)
|
|
73
|
-
|
|
74
|
-
- Automatically deploys built components
|
|
75
|
-
- Pushes to specified instance
|
|
76
|
-
- Verifies deployment status
|
|
77
|
-
|
|
78
|
-
### 5. Result Reporting
|
|
79
|
-
|
|
80
|
-
- Reports final status
|
|
81
|
-
- Shows build and deployment results
|
|
82
|
-
- Provides error details if any
|
|
83
|
-
|
|
84
|
-
## Build Status Monitoring
|
|
85
|
-
|
|
86
|
-
The command monitors build with these statuses:
|
|
87
|
-
|
|
88
|
-
- **In Progress** - Build is currently running
|
|
89
|
-
- **Passed** - Build completed successfully
|
|
90
|
-
- **Failed** - Build encountered errors
|
|
91
|
-
|
|
92
|
-
## Deployment Conditions
|
|
93
|
-
|
|
94
|
-
Deployment proceeds only if:
|
|
95
|
-
|
|
96
|
-
- All components build successfully
|
|
97
|
-
- Build status is "passed" for all components
|
|
98
|
-
- No build errors occurred
|
|
99
|
-
|
|
100
|
-
If build fails:
|
|
101
|
-
|
|
102
|
-
- Deployment is skipped
|
|
103
|
-
- Error message is displayed
|
|
104
|
-
- Process exits with build failure status
|
|
105
|
-
|
|
106
|
-
## Supported Projects
|
|
107
|
-
|
|
108
|
-
- **portal** - Portal application
|
|
109
|
-
- **gateway** - Gateway service
|
|
110
|
-
- **phr** - Personal Health Records
|
|
111
|
-
- **configService** - Configuration service
|
|
112
|
-
- **healthRecords** - Health records service
|
|
113
|
-
- **centralAuth** - Central authentication service
|
|
114
|
-
- **mpi** - Master Patient Index
|
|
115
|
-
- **phrAdminBackend** - PHR admin backend
|
|
116
|
-
- **phrAdminClient** - PHR admin client
|
|
117
|
-
- **terminologyService** - Terminology service
|
|
118
|
-
|
|
119
|
-
## Supported Components
|
|
120
|
-
|
|
121
|
-
- **client** - Frontend client application
|
|
122
|
-
- **administration** - Administration panel
|
|
123
|
-
- **provider** - Provider interface
|
|
124
|
-
- **rest-api** - REST API backend
|
|
125
|
-
|
|
126
|
-
## Supported Instances
|
|
127
|
-
|
|
128
|
-
- **dev** - Development environment
|
|
129
|
-
- **qa** - Quality assurance environment
|
|
130
|
-
- **pilot** - Pilot/staging environment
|
|
131
|
-
|
|
132
|
-
## Advantages Over Separate Commands
|
|
133
|
-
|
|
134
|
-
### Time Saving
|
|
135
|
-
|
|
136
|
-
- Single command for both operations
|
|
137
|
-
- No manual intervention needed
|
|
138
|
-
- Automatic status monitoring
|
|
139
|
-
|
|
140
|
-
### Error Prevention
|
|
141
|
-
|
|
142
|
-
- Ensures build succeeds before deploying
|
|
143
|
-
- Prevents deploying broken builds
|
|
144
|
-
- Automatic validation
|
|
145
|
-
|
|
146
|
-
### Consistency
|
|
147
|
-
|
|
148
|
-
- Standardized workflow
|
|
149
|
-
- Reduces human error
|
|
150
|
-
- Ensures proper sequence
|
|
151
|
-
|
|
152
|
-
## When to Use Build-Deploy
|
|
153
|
-
|
|
154
|
-
### Good Use Cases
|
|
155
|
-
|
|
156
|
-
- **CI/CD Pipelines**
|
|
157
|
-
|
|
158
|
-
- Automated deployment workflows
|
|
159
|
-
- Continuous integration processes
|
|
160
|
-
|
|
161
|
-
- **Quick Iterations**
|
|
162
|
-
|
|
163
|
-
- Rapid development cycles
|
|
164
|
-
- Frequent updates
|
|
165
|
-
|
|
166
|
-
- **Tested Changes**
|
|
167
|
-
- When confident in changes
|
|
168
|
-
- After local testing
|
|
169
|
-
|
|
170
|
-
### When to Use Separate Commands
|
|
171
|
-
|
|
172
|
-
- **Testing Builds First**
|
|
173
|
-
|
|
174
|
-
- When you want to verify build before deploying
|
|
175
|
-
- For critical production changes
|
|
176
|
-
|
|
177
|
-
- **Delayed Deployment**
|
|
178
|
-
|
|
179
|
-
- When deployment timing is important
|
|
180
|
-
- Scheduled deployments
|
|
181
|
-
|
|
182
|
-
- **Multiple Environments**
|
|
183
|
-
- Building once, deploying to multiple instances
|
|
184
|
-
- Staged rollouts
|
|
185
|
-
|
|
186
|
-
## Timing
|
|
187
|
-
|
|
188
|
-
### Build Wait Time
|
|
189
|
-
|
|
190
|
-
The command waits approximately **4 minutes** (240 seconds) for build completion. This is:
|
|
191
|
-
|
|
192
|
-
- Sufficient for most builds
|
|
193
|
-
- Adjustable in the code if needed
|
|
194
|
-
- Includes buffer time for larger builds
|
|
195
|
-
|
|
196
|
-
### Total Process Time
|
|
197
|
-
|
|
198
|
-
Typical execution time:
|
|
199
|
-
|
|
200
|
-
- Build: 2-5 minutes
|
|
201
|
-
- Wait: 4 minutes
|
|
202
|
-
- Deploy: 1-3 minutes
|
|
203
|
-
- **Total: 7-12 minutes**
|
|
204
|
-
|
|
205
|
-
## Troubleshooting
|
|
206
|
-
|
|
207
|
-
### Build Fails
|
|
208
|
-
|
|
209
|
-
If build fails during build-deploy:
|
|
210
|
-
|
|
211
|
-
1. **Check build logs:**
|
|
212
|
-
|
|
213
|
-
- Review error messages
|
|
214
|
-
- Identify build issues
|
|
215
|
-
|
|
216
|
-
2. **Fix issues:**
|
|
217
|
-
|
|
218
|
-
- Correct code errors
|
|
219
|
-
- Update dependencies
|
|
220
|
-
- Resolve conflicts
|
|
221
|
-
|
|
222
|
-
3. **Retry:**
|
|
223
|
-
```bash
|
|
224
|
-
nitor build-deploy -p <project> -c <component> -i <instance>
|
|
225
|
-
```
|
|
226
|
-
|
|
227
|
-
### Deployment Skipped
|
|
228
|
-
|
|
229
|
-
If "Deploy skipped" message appears:
|
|
230
|
-
|
|
231
|
-
1. **Build failed:**
|
|
232
|
-
|
|
233
|
-
- Check build error messages
|
|
234
|
-
- Fix build issues
|
|
235
|
-
- Rebuild
|
|
236
|
-
|
|
237
|
-
2. **Verify build status:**
|
|
238
|
-
```bash
|
|
239
|
-
nitor build -p <project> -c <component> -i <instance>
|
|
240
|
-
```
|
|
241
|
-
|
|
242
|
-
### Timeout Issues
|
|
243
|
-
|
|
244
|
-
If build takes longer than expected:
|
|
245
|
-
|
|
246
|
-
1. **Check build progress:**
|
|
247
|
-
|
|
248
|
-
- Monitor build system
|
|
249
|
-
- Check for stuck processes
|
|
250
|
-
|
|
251
|
-
2. **Increase wait time:**
|
|
252
|
-
- Modify wait duration in code
|
|
253
|
-
- Or use separate build/deploy commands
|
|
254
|
-
|
|
255
|
-
### Connection Errors
|
|
256
|
-
|
|
257
|
-
If deployment fails due to connection:
|
|
258
|
-
|
|
259
|
-
1. **Verify network:**
|
|
260
|
-
|
|
261
|
-
- Check internet connectivity
|
|
262
|
-
- Verify VPN if required
|
|
263
|
-
|
|
264
|
-
2. **Check credentials:**
|
|
265
|
-
- Ensure deployment credentials are valid
|
|
266
|
-
- Verify permissions
|
|
267
|
-
|
|
268
|
-
## Best Practices
|
|
269
|
-
|
|
270
|
-
### Before Running
|
|
271
|
-
|
|
272
|
-
1. **Test Locally:**
|
|
273
|
-
|
|
274
|
-
- Run tests on local machine
|
|
275
|
-
- Verify code compiles
|
|
276
|
-
|
|
277
|
-
2. **Commit Changes:**
|
|
278
|
-
|
|
279
|
-
- Ensure all changes are committed
|
|
280
|
-
- Push to repository
|
|
281
|
-
|
|
282
|
-
3. **Check Instance:**
|
|
283
|
-
- Verify target instance is correct
|
|
284
|
-
- Confirm instance is available
|
|
285
|
-
|
|
286
|
-
### During Execution
|
|
287
|
-
|
|
288
|
-
1. **Monitor Progress:**
|
|
289
|
-
|
|
290
|
-
- Watch build logs
|
|
291
|
-
- Check for errors
|
|
292
|
-
|
|
293
|
-
2. **Don't Interrupt:**
|
|
294
|
-
- Let process complete
|
|
295
|
-
- Avoid canceling mid-build
|
|
296
|
-
|
|
297
|
-
### After Completion
|
|
298
|
-
|
|
299
|
-
1. **Verify Deployment:**
|
|
300
|
-
|
|
301
|
-
- Test deployed application
|
|
302
|
-
- Check functionality
|
|
303
|
-
|
|
304
|
-
2. **Monitor Logs:**
|
|
305
|
-
- Watch application logs
|
|
306
|
-
- Check for runtime errors
|
|
307
|
-
|
|
308
|
-
## Getting Help
|
|
309
|
-
|
|
310
|
-
To see all available options:
|
|
311
|
-
|
|
312
|
-
```bash
|
|
313
|
-
nitor build-deploy -help
|
|
314
|
-
```
|
|
315
|
-
|
|
316
|
-
## Related Commands
|
|
317
|
-
|
|
318
|
-
- `nitor build` - Build only
|
|
319
|
-
- `nitor deploy` - Deploy only
|
|
320
|
-
- `nitor review` - Review before deploying
|
package/docs/CLEANUP.md
DELETED
|
@@ -1,285 +0,0 @@
|
|
|
1
|
-
# Cleanup Command Guide
|
|
2
|
-
|
|
3
|
-
## Overview
|
|
4
|
-
|
|
5
|
-
The `cleanup` command removes all local Git branches except the main branch (master or main), helping you maintain a clean local repository.
|
|
6
|
-
|
|
7
|
-
## Usage
|
|
8
|
-
|
|
9
|
-
### Basic Syntax
|
|
10
|
-
|
|
11
|
-
```bash
|
|
12
|
-
nitor cleanup
|
|
13
|
-
```
|
|
14
|
-
|
|
15
|
-
## Options
|
|
16
|
-
|
|
17
|
-
| Option | Short | Description |
|
|
18
|
-
| -------- | ------- | ----------- |
|
|
19
|
-
| `--help` | `-help` | Show help |
|
|
20
|
-
|
|
21
|
-
## What It Does
|
|
22
|
-
|
|
23
|
-
The cleanup command performs these operations:
|
|
24
|
-
|
|
25
|
-
1. **Checkout to Main Branch**
|
|
26
|
-
|
|
27
|
-
- Switches to `master` or `main` branch
|
|
28
|
-
- Ensures you're not on a branch being deleted
|
|
29
|
-
|
|
30
|
-
2. **Delete All Other Local Branches**
|
|
31
|
-
- Removes all local branches except master/main
|
|
32
|
-
- Cleans up your local repository
|
|
33
|
-
|
|
34
|
-
## Examples
|
|
35
|
-
|
|
36
|
-
### Basic Cleanup
|
|
37
|
-
|
|
38
|
-
```bash
|
|
39
|
-
nitor cleanup
|
|
40
|
-
```
|
|
41
|
-
|
|
42
|
-
This will:
|
|
43
|
-
|
|
44
|
-
- Checkout to master (or main)
|
|
45
|
-
- Delete all other local branches
|
|
46
|
-
|
|
47
|
-
## When to Use Cleanup
|
|
48
|
-
|
|
49
|
-
### Good Times to Cleanup
|
|
50
|
-
|
|
51
|
-
- **After Merging Features**
|
|
52
|
-
- When feature branches are merged and no longer needed
|
|
53
|
-
- **Regular Maintenance**
|
|
54
|
-
|
|
55
|
-
- Weekly or monthly cleanup of old branches
|
|
56
|
-
|
|
57
|
-
- **Before Starting New Work**
|
|
58
|
-
|
|
59
|
-
- Clean slate for new development
|
|
60
|
-
|
|
61
|
-
- **After Release**
|
|
62
|
-
- Remove branches from previous release cycle
|
|
63
|
-
|
|
64
|
-
### When NOT to Cleanup
|
|
65
|
-
|
|
66
|
-
- **Unmerged Work**
|
|
67
|
-
|
|
68
|
-
- If you have branches with uncommitted or unpushed work
|
|
69
|
-
|
|
70
|
-
- **Active Development**
|
|
71
|
-
|
|
72
|
-
- When working on multiple features simultaneously
|
|
73
|
-
|
|
74
|
-
- **Shared Branches**
|
|
75
|
-
- If others are collaborating on your local branches
|
|
76
|
-
|
|
77
|
-
## Important Warnings
|
|
78
|
-
|
|
79
|
-
### ⚠️ This Operation Cannot Be Undone
|
|
80
|
-
|
|
81
|
-
Once branches are deleted locally, you cannot recover them unless:
|
|
82
|
-
|
|
83
|
-
- They exist on remote
|
|
84
|
-
- You have a backup
|
|
85
|
-
|
|
86
|
-
### Before Running Cleanup
|
|
87
|
-
|
|
88
|
-
1. **Check for Uncommitted Changes**
|
|
89
|
-
|
|
90
|
-
```bash
|
|
91
|
-
git status
|
|
92
|
-
```
|
|
93
|
-
|
|
94
|
-
2. **List All Branches**
|
|
95
|
-
|
|
96
|
-
```bash
|
|
97
|
-
git branch
|
|
98
|
-
```
|
|
99
|
-
|
|
100
|
-
3. **Push Important Branches**
|
|
101
|
-
|
|
102
|
-
```bash
|
|
103
|
-
git push origin <branch-name>
|
|
104
|
-
```
|
|
105
|
-
|
|
106
|
-
4. **Verify Merged Status**
|
|
107
|
-
```bash
|
|
108
|
-
git branch --merged
|
|
109
|
-
```
|
|
110
|
-
|
|
111
|
-
## What Gets Deleted
|
|
112
|
-
|
|
113
|
-
### Deleted
|
|
114
|
-
|
|
115
|
-
- All local feature branches
|
|
116
|
-
- All local fix branches
|
|
117
|
-
- All local development branches
|
|
118
|
-
- Any other local branches except master/main
|
|
119
|
-
|
|
120
|
-
### Preserved
|
|
121
|
-
|
|
122
|
-
- `master` branch
|
|
123
|
-
- `main` branch
|
|
124
|
-
- Remote branches (not affected)
|
|
125
|
-
|
|
126
|
-
## Safe Cleanup Workflow
|
|
127
|
-
|
|
128
|
-
### Step 1: Review Branches
|
|
129
|
-
|
|
130
|
-
```bash
|
|
131
|
-
# List all local branches
|
|
132
|
-
git branch
|
|
133
|
-
|
|
134
|
-
# List merged branches
|
|
135
|
-
git branch --merged
|
|
136
|
-
|
|
137
|
-
# List unmerged branches
|
|
138
|
-
git branch --no-merged
|
|
139
|
-
```
|
|
140
|
-
|
|
141
|
-
### Step 2: Push Important Work
|
|
142
|
-
|
|
143
|
-
```bash
|
|
144
|
-
# Push specific branch
|
|
145
|
-
git push origin <branch-name>
|
|
146
|
-
|
|
147
|
-
# Or push all branches
|
|
148
|
-
git push --all
|
|
149
|
-
```
|
|
150
|
-
|
|
151
|
-
### Step 3: Run Cleanup
|
|
152
|
-
|
|
153
|
-
```bash
|
|
154
|
-
nitor cleanup
|
|
155
|
-
```
|
|
156
|
-
|
|
157
|
-
### Step 4: Verify
|
|
158
|
-
|
|
159
|
-
```bash
|
|
160
|
-
# Check remaining branches
|
|
161
|
-
git branch
|
|
162
|
-
```
|
|
163
|
-
|
|
164
|
-
## Recovering Deleted Branches
|
|
165
|
-
|
|
166
|
-
If you accidentally delete a branch:
|
|
167
|
-
|
|
168
|
-
### If Branch Exists on Remote
|
|
169
|
-
|
|
170
|
-
```bash
|
|
171
|
-
# Fetch from remote
|
|
172
|
-
git fetch origin
|
|
173
|
-
|
|
174
|
-
# Checkout remote branch
|
|
175
|
-
git checkout -b <branch-name> origin/<branch-name>
|
|
176
|
-
```
|
|
177
|
-
|
|
178
|
-
### If Branch Was Recently Deleted
|
|
179
|
-
|
|
180
|
-
```bash
|
|
181
|
-
# Find the commit hash
|
|
182
|
-
git reflog
|
|
183
|
-
|
|
184
|
-
# Recreate branch from commit
|
|
185
|
-
git checkout -b <branch-name> <commit-hash>
|
|
186
|
-
```
|
|
187
|
-
|
|
188
|
-
## Alternative: Manual Cleanup
|
|
189
|
-
|
|
190
|
-
If you prefer more control:
|
|
191
|
-
|
|
192
|
-
### Delete Specific Branch
|
|
193
|
-
|
|
194
|
-
```bash
|
|
195
|
-
git branch -d <branch-name>
|
|
196
|
-
```
|
|
197
|
-
|
|
198
|
-
### Force Delete Branch
|
|
199
|
-
|
|
200
|
-
```bash
|
|
201
|
-
git branch -D <branch-name>
|
|
202
|
-
```
|
|
203
|
-
|
|
204
|
-
### Delete Multiple Branches
|
|
205
|
-
|
|
206
|
-
```bash
|
|
207
|
-
git branch | grep -v "master\|main" | xargs git branch -D
|
|
208
|
-
```
|
|
209
|
-
|
|
210
|
-
## Troubleshooting
|
|
211
|
-
|
|
212
|
-
### Cannot Delete Current Branch
|
|
213
|
-
|
|
214
|
-
If you're on a branch being deleted:
|
|
215
|
-
|
|
216
|
-
```bash
|
|
217
|
-
git checkout master
|
|
218
|
-
nitor cleanup
|
|
219
|
-
```
|
|
220
|
-
|
|
221
|
-
### Branch Has Unmerged Changes
|
|
222
|
-
|
|
223
|
-
If a branch has unmerged changes:
|
|
224
|
-
|
|
225
|
-
1. **Review changes:**
|
|
226
|
-
|
|
227
|
-
```bash
|
|
228
|
-
git log master..<branch-name>
|
|
229
|
-
```
|
|
230
|
-
|
|
231
|
-
2. **Merge if needed:**
|
|
232
|
-
|
|
233
|
-
```bash
|
|
234
|
-
nitor merge -s <branch-name> -ta master
|
|
235
|
-
```
|
|
236
|
-
|
|
237
|
-
3. **Then cleanup:**
|
|
238
|
-
```bash
|
|
239
|
-
nitor cleanup
|
|
240
|
-
```
|
|
241
|
-
|
|
242
|
-
### Master/Main Branch Not Found
|
|
243
|
-
|
|
244
|
-
If neither master nor main exists:
|
|
245
|
-
|
|
246
|
-
1. Create one:
|
|
247
|
-
```bash
|
|
248
|
-
git checkout -b master
|
|
249
|
-
```
|
|
250
|
-
2. Then run cleanup
|
|
251
|
-
|
|
252
|
-
## Best Practices
|
|
253
|
-
|
|
254
|
-
### Regular Cleanup Schedule
|
|
255
|
-
|
|
256
|
-
- **Weekly** - For active projects
|
|
257
|
-
- **After Each Sprint** - For agile teams
|
|
258
|
-
- **After Releases** - For release-based workflows
|
|
259
|
-
|
|
260
|
-
### Pre-Cleanup Checklist
|
|
261
|
-
|
|
262
|
-
- [ ] All important work is committed
|
|
263
|
-
- [ ] All important branches are pushed to remote
|
|
264
|
-
- [ ] No active work in progress
|
|
265
|
-
- [ ] Team members notified (if applicable)
|
|
266
|
-
|
|
267
|
-
### Post-Cleanup Verification
|
|
268
|
-
|
|
269
|
-
- [ ] Only master/main remains locally
|
|
270
|
-
- [ ] Remote branches still accessible
|
|
271
|
-
- [ ] No important work lost
|
|
272
|
-
|
|
273
|
-
## Getting Help
|
|
274
|
-
|
|
275
|
-
To see all available options:
|
|
276
|
-
|
|
277
|
-
```bash
|
|
278
|
-
nitor cleanup -help
|
|
279
|
-
```
|
|
280
|
-
|
|
281
|
-
## Related Commands
|
|
282
|
-
|
|
283
|
-
- `nitor merge` - Merge branches before cleanup
|
|
284
|
-
- `nitor create-branch` - Create new branches after cleanup
|
|
285
|
-
- Standard Git commands for branch management
|