gitbash 1.6.2 → 1.6.3

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.
Files changed (5) hide show
  1. package/README.md +1 -1
  2. package/docs/CONTRIBUTING.md +138 -0
  3. package/docs/SECURITY.md +63 -0
  4. package/package.json +2 -2
  5. /package/{doc → docs}/screenshot-status.png +0 -0
package/README.md CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
  Interactive git utilities for bash with fzf-powered menus.
4
4
 
5
- ![screenshot-status.png](./doc/screenshot-status.png)
5
+ ![screenshot-status.png](./docs/screenshot-status.png)
6
6
 
7
7
  ## Installation
8
8
 
package/docs/CONTRIBUTING.md ADDED
@@ -0,0 +1,138 @@
1
+ # Contributing to gitbash
2
+
3
+ Thank you for your interest in contributing to gitbash! This document outlines the process and guidelines for contributing to this project.
4
+
5
+ ## Getting Started
6
+
7
+ 1. Fork the repository
8
+ 2. Clone your fork locally
9
+ 3. Create a feature or bugfix branch (see Branch Naming below)
10
+ 4. Make your changes
11
+ 5. Add a changeset (see Changesets below)
12
+ 6. Push your branch and create a Pull Request
13
+
14
+ ## Branch Naming
15
+
16
+ All contributions **must** be made through feature or bugfix branches. Direct commits to `main` won't be merged.
17
+
18
+ ### Branch naming convention:
19
+ - **Feature branches**: `feature/<issue-number>-<description>` or `feature/NOISSUE-<description>`
20
+ - **Bugfix branches**: `bugfix/<issue-number>-<description>` or `bugfix/NOISSUE-<description>`
21
+
22
+ Examples:
23
+ ```bash
24
+ feature/42-add-rebase-command
25
+ feature/NOISSUE-improve-error-messages
26
+ bugfix/15-fix-stale-branch-filtering
27
+ bugfix/NOISSUE-fix-typo-in-help
28
+ ```
29
+
30
+ You can use the built-in `gitbash create` command to create properly formatted branches:
31
+ ```bash
32
+ ./bin/gitbash create
33
+ ```
34
+
35
+ ## Pull Requests
36
+
37
+ All contributions must be submitted via Pull Request (PR):
38
+
39
+ 1. **One feature/fix per PR** - Keep PRs focused and atomic
40
+ 2. **Descriptive title** - Clearly describe what the PR does
41
+ 3. **Description** - Explain the motivation and implementation details
42
+ 4. **Reference issues** - Link to related issues if applicable
43
+ 5. **Include a changeset** - See below for details
44
+
45
+ ### PR Requirements:
46
+ - [ ] Branch follows naming convention (`feature/*` or `bugfix/*`)
47
+ - [ ] Changeset has been added
48
+ - [ ] Code works as intended
49
+ - [ ] No breaking changes (unless discussed and approved)
50
+
51
+ ## Changesets
52
+
53
+ We use [Changesets](https://github.com/changesets/changesets) to manage versions and changelogs. **Every PR must include a changeset.**.
54
+
55
+ ### How to add a changeset:
56
+
57
+ 1. After making your changes, run:
58
+ ```bash
59
+ npm run changeset
60
+ ```
61
+
62
+ 2. You'll be prompted to select the change type:
63
+ - **patch** - Bug fixes, small improvements (1.0.0 → 1.0.1)
64
+ - **minor** - New features, non-breaking changes (1.0.0 → 1.1.0)
65
+ - **major** - Breaking changes (1.0.0 → 2.0.0)
66
+
67
+ 3. Write a clear, user-facing description of the change:
68
+ ```
69
+ Added --all option to stale command to show all branches by default
70
+ ```
71
+
72
+ 4. A changeset file will be created in `.changeset/` - commit this with your PR:
73
+ ```bash
74
+ ./bin/gitbash commit "feat: Add changeset for stale command enhancement"
75
+ ```
76
+
77
+ ### Example changeset workflow:
78
+
79
+ ```bash
80
+ # 1. Create your feature branch
81
+ ./bin/gitbash create
82
+ # Select "feature", enter "NOISSUE" or issue number, add description
83
+
84
+ # 2. Make your changes
85
+ vim commands/stale.sh
86
+
87
+ # 3. Add a changeset
88
+ npm run changeset
89
+ # Select "minor" (new feature)
90
+ # Enter: "Added --all option to stale command to start in all branches mode"
91
+
92
+ # 4. Commit everything
93
+ ./bin/gitbash commit "feat: add --all option to stale command"
94
+
95
+ # 5. Push and create PR
96
+ ./bin/gitbash pr -p
97
+ ```
98
+
99
+ ### What happens to changesets:
100
+
101
+ When your PR is merged:
102
+ 1. The changeset file is included in the main branch
103
+ 2. When ready for release, maintainers run `npm run version`
104
+ 3. Changesets are consumed and version is bumped
105
+ 4. CHANGELOG.md is automatically updated
106
+ 5. Changes are published with `npm run release`
107
+
108
+ ## Development Guidelines
109
+
110
+ ### Testing your changes:
111
+ ```bash
112
+ # Test the gitbash command directly
113
+ ./bin/gitbash <command>
114
+
115
+ # Example: test the stale command
116
+ ./bin/gitbash stale --all
117
+ ```
118
+
119
+ ### Code style:
120
+ - Follow existing bash script conventions
121
+ - Use shellcheck for linting when possible
122
+ - Keep functions focused and well-documented
123
+ - Include help text for new commands/options
124
+ - Keep the readme updated and as terse as possible
125
+
126
+ ### Documentation:
127
+ - Update command help text (`-h, --help`) for new features
128
+ - Update README.md if adding new commands
129
+ - Add usage examples for new features
130
+
131
+ ## Questions or Issues?
132
+
133
+ If you have questions or run into issues:
134
+ - Check existing issues and discussions
135
+ - Create a new issue for bugs or feature requests
136
+ - Reach out in your PR if you need guidance
137
+
138
+ Thank you for contributing! 🎉 You rock!
package/docs/SECURITY.md ADDED
@@ -0,0 +1,63 @@
1
+ # Security Policy
2
+
3
+ ## Supported Versions
4
+
5
+ The following versions of this project are currently receiving security updates:
6
+
7
+ | Version | Supported |
8
+ |--------|-----------|
9
+ | 1.x.x | ✅ |
10
+ | < 1.0 | ❌ |
11
+
12
+ Security fixes are only applied to the latest minor/patch release of the **1.x.x** series. Older versions must be upgraded to receive patches.
13
+
14
+ ---
15
+
16
+ ## Reporting a Vulnerability
17
+
18
+ We take security vulnerabilities seriously and appreciate your efforts to responsibly disclose them.
19
+
20
+ ### How to Report
21
+
22
+ - **Email:** `matthias.jaeggli@gmail.com`
23
+ - **Do not** open a public GitHub issue for security concerns.
24
+
25
+ ### Response Expectations
26
+
27
+ - We will acknowledge your report **within 48 hours**.
28
+ - You will receive progress updates **at least weekly** until the issue is resolved.
29
+ - If additional information is needed, we will contact you directly.
30
+
31
+ ### After You Report
32
+
33
+ After we receive your report:
34
+
35
+ 1. We assess and validate the vulnerability.
36
+ 2. If confirmed, we classify its severity and begin developing a fix.
37
+ 3. We work with you on a responsible disclosure timeline.
38
+ 4. A patched release is published along with a security advisory.
39
+ 5. If the issue is not accepted, we will explain why.
40
+
41
+ ### Responsible Disclosure
42
+
43
+ To protect users, please avoid public disclosure until:
44
+
45
+ - A fix has been released, **or**
46
+ - 30 days have passed since we acknowledged the report (unless otherwise agreed).
47
+
48
+ ---
49
+
50
+ ## Preferred Report Format
51
+
52
+ When reporting, please include:
53
+
54
+ - A description of the vulnerability.
55
+ - Steps to reproduce or a proof-of-concept.
56
+ - Expected vs. actual behavior.
57
+ - Affected versions.
58
+ - Impact and severity (if known).
59
+ - Optional: suggested remediation ideas.
60
+
61
+ ---
62
+
63
+ Thank you for helping improve the security of this project.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "gitbash",
3
- "version": "1.6.2",
3
+ "version": "1.6.3",
4
4
  "description": "Opinionated git utilities for bash with fzf-powered menus",
5
5
  "author": "jaggli",
6
6
  "license": "MIT",
@@ -29,7 +29,7 @@
29
29
  "files": [
30
30
  "bin/",
31
31
  "commands/",
32
- "doc/",
32
+ "docs/",
33
33
  "README.md",
34
34
  "LICENSE"
35
35
  ],
/package/{doc → docs}/screenshot-status.png RENAMED
File without changes