Contributions to zsh-tmux are welcome.
Feel free to use all of the contribution options:
In general, MRs are welcome. We follow the typical "fork-and-pull" Github flow.
-
Fork the repo on Github
-
Clone the project to your own machine
-
Commit changes to your own branch using Github Flow
-
Push your work back up to your fork
-
Submit a Pull Request so that we can review your changes
NOTE: Be sure to rebase the latest changes from "upstream" before making a pull request!
Your commit messages should serve these 3 important purposes:
- To speed up the reviewing process.
- To provide the least amount of necessary documentation
- To help the future maintainers.
Follow the repository commit format enforced by commitlint: <type> <emoji> (<scope>): <subject>. The repository currently accepts scopes core, accounts, and ci, with a maximum subject length of 100 characters.
chore: something just needs to happen, e.g. versioning
docs: documentation pages in docs/ or docstrings
feat: new code in ./
fix: code improvement in ./
refactor: code movement in ./
style: aesthetic changes
test: test case modifications in test/
Examples commit messages:
- chore 🧹 (core): refresh release metadata
- docs 📚 (core): update configuration paths
- feat ✨ (core): add tmux workflow helpers
- fix 🐛 (core): correct sync destination
- refactor 🎨 (core): simplify tmux helper flow
- style 💄 (core): normalize shell formatting
- test 🧪 (core): cover sync commands
Keep it short and simple!
See Github Flow.
Documentation is part of the zsh-tmux code base. You can find the documentation files in the docs/ directory of the main repository. README.md is generated from provision/generators/README.yaml, provision/templates/README.tpl.md, and the included files under docs/.
See Testing.
- See if a Pull Request exists
- Add some comments or review the code to help it along
- Don't be afraid to comment when logic needs clarification
- Create a Fork and open a Pull Request if needed
- Anyone can review code
- Any Pull Request should be closed or merged within a week
Try to keep history as linear as possible using a [rebase] merge strategy.