From c2c33f0b4f8ff9ad8472b607c3ab960b8baf2934 Mon Sep 17 00:00:00 2001 From: Karan Anand Date: Sun, 2 Mar 2025 23:09:54 -0800 Subject: [PATCH 1/7] docs: add a Git cheatsheet for stdlib --- type: pre_push_report description: Results of running various checks prior to pushing changes. report: - task: run_javascript_examples status: na - task: run_c_examples status: na - task: run_cpp_examples status: na - task: run_javascript_readme_examples status: na - task: run_c_benchmarks status: na - task: run_cpp_benchmarks status: na - task: run_fortran_benchmarks status: na - task: run_javascript_benchmarks status: na - task: run_julia_benchmarks status: na - task: run_python_benchmarks status: na - task: run_r_benchmarks status: na - task: run_javascript_tests status: na --- --- docs/contributing/git_cheatsheet.md | 302 ++++++++++++++++++++++++++++ 1 file changed, 302 insertions(+) create mode 100644 docs/contributing/git_cheatsheet.md diff --git a/docs/contributing/git_cheatsheet.md b/docs/contributing/git_cheatsheet.md new file mode 100644 index 000000000000..3167597686da --- /dev/null +++ b/docs/contributing/git_cheatsheet.md @@ -0,0 +1,302 @@ + + +# Git Cheatsheet + +> Git Cheatsheet for stdlib + +## Introduction + +Welcome to `stdlib`! [Git][git] can feel overwhelming at times, but don't worry! This cheatsheet will walk you through the essential Git commands you'll need in a structured and easy-to-follow manner. Think of it as your go-to guide for a smooth and hassle-free workflow. + +## Configuration + +Before you start using [Git][git], it's important to introduce yourself. This step ensures that your commits are linked to your identity, making it easier to track contributions. + + + +```bash +git config --global user.name "Your Name" +git config --global user.email "your.email@example.com" +``` + +> You only need to do this once. + +To confirm that your identity is set correctly, run: + + + +```bash +git config --global user.name +git config --global user.email +``` + +This should display the name and email you configured. If there's a mistake, simply re-run the configuration commands with the correct details. + +## Cloning + +To contribute to `stdlib`, you first need to [fork][github-fork] the repository on GitHub. This creates a copy of the repository under your GitHub account where you have write access. + +Once you've forked the repository, clone your fork onto your local machine: + + + +```bash +git clone https://github.com/YOUR_GITHUB_USERNAME/stdlib.git +cd stdlib +``` + +Since the official `stdlib` repository keeps updating, link it as the [upstream][git-remotes] remote to fetch the latest changes: + + + +```bash +git remote add upstream https://github.com/stdlib-js/stdlib.git +git fetch upstream +``` + +> In [Git][git], a [remote][github-remote] is a reference to a repository. Your fork is called `origin`, while the official `stdlib` repository is referred to as `upstream`. Adding an upstream remote allows you to consistently fetch the latest updates from the original repository and incorporate them into your work. + +## Branching + +In `stdlib`, the `develop` branch is the primary branch for development. Instead of making changes directly in the `develop` branch of your forked repository, it's best to create a separate branch for each feature or fix. This keeps your `develop` branch clean and makes it easier to pull updates from the official repository. To create a new branch for your work, use: + + + +```bash +git checkout -b feature/my-new-feature +``` + +## Changes + +Now comes the fun part of actually writing code! After making your changes, it's always good to check what’s modified: + + + +```bash +git status +``` + +Once you're happy with your changes, add them to the staging area for a final confirmation: + + + +```bash +git add # Add specific files +git add . # Add all changes +``` + +Then, commit with a meaningful message: + + + +```bash +git commit -m "feat: add support for new function" +``` + +Try to keep your commit messages clear and concise! Adhering to stdlib's [Git Style Guide][github-style-guide] ensures a well-structured and understandable commit history. + +## Pushing + +Once your branch is ready, you need to push your **local** changes to your forked repository on GitHub using: + + + +```bash +git push +``` + +If this is the first time you’re pushing the branch, [Git][git] may prompt you to set an upstream branch. You can do this manually by running: + + + +```bash +git push --set-upstream origin feature/my-new-feature +``` + +> **Note:** This is a **one-time setup** for this branch. After this, you can simply use `git push` for future updates. + +Once pushed, your changes will be available on GitHub, and you can proceed to create a pull request. + +## Pull Request + +A pull request (PR) is a way to suggest changes to a project. It lets maintainers review your work, give feedback, and approve the changes before adding them to the main repository. This is how you officially submit your contributions to `stdlib` after pushing your changes: + +1. Go to your fork on GitHub. +2. Click "Compare & pull request." +3. Add a clear title and description (mention what you changed and why). + +Once you create your pull request, a review request will be **automatically** sent to the maintainers via `stdlib-bot`. Your code will then be reviewed, and you may need to make some tweaks before it gets merged. + +## Syncing + +The `develop` branch of your forked repository should always stay **identical** to the official `stdlib` repository. If you accidentally add commits to your local `develop` branch, you need to remove them before updating it. + +To update your local `develop` branch while making sure there are no unwanted changes, run: + + + +```bash +git checkout develop +git pull --ff-only upstream develop +``` + +> **Why use `--ff-only`?** +> This ensures your branch updates **only if no merge commits are needed**. If your `develop` branch has unexpected changes, this command will fail, alerting you that something is wrong. + +If the above pull fails because you accidentally made changes to `develop`, you can **reset** it to match the official repository: + + + +```bash +git checkout develop +git reset --hard upstream/develop +``` + +> **Warning:** This will delete any changes you made to `develop`. Make sure you don’t have important work in this branch before running this command. + +After updating `develop`, you can push it to your fork to keep everything in sync: + + + +```bash +git push origin develop +``` + +## Integration + +While working on a feature branch, new changes might be added to the `develop` branch after syncing it as described above. To ensure your feature branch stays updated with these latest changes, you need to integrate them before pushing your work. There are two main ways to do this: rebasing and merging. + +### Rebase + +Rebasing **moves** your commits on top of the latest `develop`, as if you had started working after the newest updates. + +#### Steps to Rebase: + + + +```bash +git checkout feature/my-branch +git rebase develop +``` + +If there are conflicts, resolve them and continue: + + + +```bash +git add +git rebase --continue +``` + +#### Example: How Rebase Works + +Before rebasing (`develop` has new commits `C` and `D`): +``` + X---Y---Z (feature/my-branch) + / +A---B---C---D (develop) +``` +After rebasing (`X, Y, Z` are reapplied on top of `D`): +``` + X'--Y'--Z' (feature/my-branch, rebased) + / +A---B---C---D (develop) +``` + +### Merge + +Merging **combines** your feature branch with `develop`, keeping both histories intact and adding a new merge commit. + +#### Steps to Merge: + + + +```bash +git checkout feature/my-branch +git merge develop +``` + +If there are conflicts, resolve them, then commit the merge. Finally, push the updated branch: + + + +```bash +git push origin feature/my-branch +``` + +> Alternatively, if you have a running PR and want to update that branch directly to the `stdlib` develop branch, comment `/stdlib merge` on the PR, wait for the bot to merge your branch automatically, and then run `git pull`. + +#### Example: How Merge Works + +Before merging (`develop` has new commits `C` and `D`): +``` + X---Y---Z (feature/my-branch) + / +A---B---C---D (develop) +``` +After merging (`W` is a new merge commit): +``` + X---Y---Z---W (feature/my-branch, merged) + / / +A---B---C-------D (develop) +``` + +### Which one should you use? + +Use **Rebase** if: +- You want a clean, linear history. +- You are working alone or sure that no one else depends on your commits. + +Use **Merge** if: +- You want a safer approach that doesn’t rewrite history. +- You are unsure about rebase or are collaborating on the branch. + +> **When in doubt, use merge.** It is safer and avoids potential conflicts caused by rewriting history. If you use the GitHub UI to update your branches, it also performs a merge. + +## Conclusion + +Congratulations! You now have all the essential Git commands to navigate your workflow smoothly while contributing to `stdlib`. Whether you're fixing a bug, adding a feature, or just getting started, this cheatsheet will help you stay organized and avoid common pitfalls. Keep practicing, stay curious, and enjoy the process. Happy coding! + +To get started with your first contribution, check out the [Contributing Guide][stdlib-contributing] and [Development Guide][stdlib-development]. If you have any further questions, feel free to join our [Gitter][stdlib-gitter] channel to connect with the community and get support. + +
+ +[stdlib-contributing]: https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md + +[stdlib-development]: https://github.com/stdlib-js/stdlib/blob/develop/docs/contributing/development.md + +[stdlib-gitter]: https://app.gitter.im/#/room/#stdlib-js_stdlib:gitter.im + +[git]: http://git-scm.com/ + +[github-remote]: https://help.github.com/articles/configuring-a-remote-for-a-fork/ + +[git-clone-depth]: https://git-scm.com/docs/git-clone#git-clone---depthltdepthgt + +[git-remotes]: https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes + +[github-fork]: https://help.github.com/articles/fork-a-repo/ + +[github-style-guide]: https://github.com/stdlib-js/stdlib/tree/develop/docs/style-guides/git#git-commit-messages + +
+ + From a91f68b832d71b1c500d743da0c7520393c09a53 Mon Sep 17 00:00:00 2001 From: Karan Anand Date: Sun, 2 Mar 2025 23:26:12 -0800 Subject: [PATCH 2/7] chore: fix linting issues --- type: pre_commit_static_analysis_report description: Results of running static analysis checks when committing changes. report: - task: lint_filenames status: passed - task: lint_editorconfig status: passed - task: lint_markdown status: passed - task: lint_package_json status: na - task: lint_repl_help status: na - task: lint_javascript_src status: na - task: lint_javascript_cli status: na - task: lint_javascript_examples status: na - task: lint_javascript_tests status: na - task: lint_javascript_benchmarks status: na - task: lint_python status: na - task: lint_r status: na - task: lint_c_src status: na - task: lint_c_examples status: na - task: lint_c_benchmarks status: na - task: lint_c_tests_fixtures status: na - task: lint_shell status: na - task: lint_typescript_declarations status: na - task: lint_typescript_tests status: na - task: lint_license_headers status: passed --- --- type: pre_push_report description: Results of running various checks prior to pushing changes. report: - task: run_javascript_examples status: na - task: run_c_examples status: na - task: run_cpp_examples status: na - task: run_javascript_readme_examples status: na - task: run_c_benchmarks status: na - task: run_cpp_benchmarks status: na - task: run_fortran_benchmarks status: na - task: run_javascript_benchmarks status: na - task: run_julia_benchmarks status: na - task: run_python_benchmarks status: na - task: run_r_benchmarks status: na - task: run_javascript_tests status: na --- --- docs/contributing/git_cheatsheet.md | 38 +++++++++++++++++------------ 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/docs/contributing/git_cheatsheet.md b/docs/contributing/git_cheatsheet.md index 3167597686da..64c19b310340 100644 --- a/docs/contributing/git_cheatsheet.md +++ b/docs/contributing/git_cheatsheet.md @@ -139,9 +139,9 @@ Once pushed, your changes will be available on GitHub, and you can proceed to cr A pull request (PR) is a way to suggest changes to a project. It lets maintainers review your work, give feedback, and approve the changes before adding them to the main repository. This is how you officially submit your contributions to `stdlib` after pushing your changes: -1. Go to your fork on GitHub. -2. Click "Compare & pull request." -3. Add a clear title and description (mention what you changed and why). +1. Go to your fork on GitHub. +2. Click "Compare & pull request." +3. Add a clear title and description (mention what you changed and why). Once you create your pull request, a review request will be **automatically** sent to the maintainers via `stdlib-bot`. Your code will then be reviewed, and you may need to make some tweaks before it gets merged. @@ -188,7 +188,7 @@ While working on a feature branch, new changes might be added to the `develop` b Rebasing **moves** your commits on top of the latest `develop`, as if you had started working after the newest updates. -#### Steps to Rebase: +#### Steps to Rebase @@ -209,13 +209,16 @@ git rebase --continue #### Example: How Rebase Works Before rebasing (`develop` has new commits `C` and `D`): -``` + +```plaintext X---Y---Z (feature/my-branch) / A---B---C---D (develop) ``` + After rebasing (`X, Y, Z` are reapplied on top of `D`): -``` + +```plaintext X'--Y'--Z' (feature/my-branch, rebased) / A---B---C---D (develop) @@ -225,7 +228,7 @@ A---B---C---D (develop) Merging **combines** your feature branch with `develop`, keeping both histories intact and adding a new merge commit. -#### Steps to Merge: +#### Steps to Merge @@ -247,27 +250,32 @@ git push origin feature/my-branch #### Example: How Merge Works Before merging (`develop` has new commits `C` and `D`): -``` + +```plaintext X---Y---Z (feature/my-branch) / A---B---C---D (develop) ``` + After merging (`W` is a new merge commit): -``` + +```plaintext X---Y---Z---W (feature/my-branch, merged) / / A---B---C-------D (develop) ``` -### Which one should you use? +### Choosing the Right One Use **Rebase** if: -- You want a clean, linear history. -- You are working alone or sure that no one else depends on your commits. + +- You want a clean, linear history. +- You are working alone or sure that no one else depends on your commits. Use **Merge** if: -- You want a safer approach that doesn’t rewrite history. -- You are unsure about rebase or are collaborating on the branch. + +- You want a safer approach that doesn’t rewrite history. +- You are unsure about rebase or are collaborating on the branch. > **When in doubt, use merge.** It is safer and avoids potential conflicts caused by rewriting history. If you use the GitHub UI to update your branches, it also performs a merge. @@ -289,8 +297,6 @@ To get started with your first contribution, check out the [Contributing Guide][ [github-remote]: https://help.github.com/articles/configuring-a-remote-for-a-fork/ -[git-clone-depth]: https://git-scm.com/docs/git-clone#git-clone---depthltdepthgt - [git-remotes]: https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes [github-fork]: https://help.github.com/articles/fork-a-repo/ From c22efc37e82438a65bad53c133bcd78b504f585f Mon Sep 17 00:00:00 2001 From: Athan Date: Tue, 18 Mar 2025 00:17:52 -0700 Subject: [PATCH 3/7] docs: update copy Signed-off-by: Athan --- docs/contributing/git_cheatsheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/git_cheatsheet.md b/docs/contributing/git_cheatsheet.md index 64c19b310340..864427210d84 100644 --- a/docs/contributing/git_cheatsheet.md +++ b/docs/contributing/git_cheatsheet.md @@ -20,7 +20,7 @@ limitations under the License. # Git Cheatsheet -> Git Cheatsheet for stdlib +> A cheatsheet for using Git to develop stdlib. ## Introduction From 818e90eebd4e39229fe3e9f87bb82a9d8480cc45 Mon Sep 17 00:00:00 2001 From: Karan Anand Date: Wed, 26 Mar 2025 18:19:01 -0700 Subject: [PATCH 4/7] docs: add a section for conflicts and example workflow --- type: pre_commit_static_analysis_report description: Results of running static analysis checks when committing changes. report: - task: lint_filenames status: passed - task: lint_editorconfig status: passed - task: lint_markdown status: passed - task: lint_package_json status: na - task: lint_repl_help status: na - task: lint_javascript_src status: na - task: lint_javascript_cli status: na - task: lint_javascript_examples status: na - task: lint_javascript_tests status: na - task: lint_javascript_benchmarks status: na - task: lint_python status: na - task: lint_r status: na - task: lint_c_src status: na - task: lint_c_examples status: na - task: lint_c_benchmarks status: na - task: lint_c_tests_fixtures status: na - task: lint_shell status: na - task: lint_typescript_declarations status: na - task: lint_typescript_tests status: na - task: lint_license_headers status: passed --- --- type: pre_push_report description: Results of running various checks prior to pushing changes. report: - task: run_javascript_examples status: na - task: run_c_examples status: na - task: run_cpp_examples status: na - task: run_javascript_readme_examples status: na - task: run_c_benchmarks status: na - task: run_cpp_benchmarks status: na - task: run_fortran_benchmarks status: na - task: run_javascript_benchmarks status: na - task: run_julia_benchmarks status: na - task: run_python_benchmarks status: na - task: run_r_benchmarks status: na - task: run_javascript_tests status: na --- --- docs/contributing/git_cheatsheet.md | 206 +++++++++++++++++++++++++++- 1 file changed, 202 insertions(+), 4 deletions(-) diff --git a/docs/contributing/git_cheatsheet.md b/docs/contributing/git_cheatsheet.md index 864427210d84..0718946f4066 100644 --- a/docs/contributing/git_cheatsheet.md +++ b/docs/contributing/git_cheatsheet.md @@ -72,7 +72,7 @@ git remote add upstream https://github.com/stdlib-js/stdlib.git git fetch upstream ``` -> In [Git][git], a [remote][github-remote] is a reference to a repository. Your fork is called `origin`, while the official `stdlib` repository is referred to as `upstream`. Adding an upstream remote allows you to consistently fetch the latest updates from the original repository and incorporate them into your work. +> In [Git][git], a [remote][github-remote] is a reference to a repository. Your fork is called `origin`, while the official `stdlib` repository is referred to as `upstream`. Adding an [upstream][git-remotes] remote allows you to consistently fetch the latest updates from the original repository and incorporate them into your work. ## Branching @@ -111,6 +111,40 @@ Then, commit with a meaningful message: git commit -m "feat: add support for new function" ``` +For **multi-line** commit messages (like when you want to include a longer description), you can use: + + + +```bash +git commit +``` + +This opens an editor where you can write something like: + +```bash +feat: add support for new function + +This adds the initial version of , with support for . +``` + +**After writing your message:** + +- **Vim**: press `Esc`, type `:wq`, then press `Enter` +- **Nano**: `Ctrl+O`, then `Enter`, then `Ctrl+X` +- **VS Code**: save and close the editor + +> Multi-line commits are especially useful for giving extra context on why the change was made, or summarizing multiple related changes. + +To make this even easier, you can also use: + + + +```bash +make commit +``` + +This gives you an interactive prompt to help you craft a properly formatted commit message. Super handy! + Try to keep your commit messages clear and concise! Adhering to stdlib's [Git Style Guide][github-style-guide] ensures a well-structured and understandable commit history. ## Pushing @@ -123,7 +157,7 @@ Once your branch is ready, you need to push your **local** changes to your forke git push ``` -If this is the first time you’re pushing the branch, [Git][git] may prompt you to set an upstream branch. You can do this manually by running: +If this is the first time you’re pushing the branch, [Git][git] may prompt you to set an [upstream][git-remotes] branch. You can do this manually by running: @@ -158,8 +192,7 @@ git checkout develop git pull --ff-only upstream develop ``` -> **Why use `--ff-only`?** -> This ensures your branch updates **only if no merge commits are needed**. If your `develop` branch has unexpected changes, this command will fail, alerting you that something is wrong. +> **Why use `--ff-only`?** This ensures your branch updates **only if no merge commits are needed**. If your `develop` branch has unexpected changes, this command will fail, alerting you that something is wrong. If the above pull fails because you accidentally made changes to `develop`, you can **reset** it to match the official repository: @@ -279,6 +312,171 @@ Use **Merge** if: > **When in doubt, use merge.** It is safer and avoids potential conflicts caused by rewriting history. If you use the GitHub UI to update your branches, it also performs a merge. +## Merge Conflicts + +Merge conflicts occur when Git can't automatically resolve differences between two commits (e.g., your branch and `develop`). This usually happens when you rebase or merge branches with conflicting changes. This is how a conflict looks in a file: + +```plaintext +function isEven(x) { +<<<<<<< HEAD + return ( x % 2 ) === 0; +======= + return ( x & 1 ) === 0; +>>>>>>> feature/bitwise-check +} +``` + +> Note: The `HEAD` section represents your current branch (`feature/bitwise-check`), while the `incoming` section represents the branch you're merging or rebasing (e.g., `develop`). + +To resolve a merge conflict: + +- Open the file in your editor. +- Choose which changes to keep. +- Remove the conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`). +- Save the file. +- Add the file to the staging area. +- Continue the rebase or merge process. + +### Example + +We will consider the conflict in the `isEven` function above. Let's say you want to keep your changes and use the bitwise AND operator (`&`) instead of the modulo operator (`%`). Here's how you can resolve the conflict: + +- Modify the file to look like this: + + ```plaintext + function isEven(x) { + return ( x & 1 ) === 0; + } + ``` + +- Add the file to the staging area: + + + + ```bash + git add + ``` + +- Continue the rebase or merge: + + + + ```bash + git rebase --continue # If rebasing + git merge --continue # If merging + ``` + +> **Tip:** Many editors like VS Code highlight conflicts and even give you buttons to accept incoming or current changes. This can make resolving conflicts much easier. + +Merge conflicts can be annoying, but they’re a natural part of working with others. Take your time, and don’t hesitate to ask for help if you're stuck. + +## Example Workflow + +Now that you have all the essential commands, let's put them together in a typical workflow: + +**Goal**: Add a new function `isEven` to `stdlib`. + +Assuming you've already cloned the repository and set up your identity: + +1. **Sync `develop`**: + + + + ```bash + git checkout develop + git pull --ff-only upstream develop + git push origin develop # Optional: Update your fork + ``` + +2. **Create a new branch**: + + + + ```bash + git checkout -b feature/is-even + ``` + +3. **Make changes**: This could involve adding the new function, writing tests, benchmarks, examples, updating documentation, etc. + +4. **Commit your changes**: + + + + ```bash + git status # Optional: Check what's modified + git add . + git commit -m "feat: add isEven function" + ``` + + If you prefer a multi-line commit message, use: + + + + ```bash + git commit + ``` + + Then write your message like: + + ```plaintext + feat: add isEven function + + This adds the complete implementation of the isEven function, along with benchmarks, examples, tests, and documentation. The implementation is based on the modulo operator. + ``` + + Save and close the editor. As mentioned earlier, you can also use `make commit` for an interactive prompt. + +5. **Push your branch**: + + + + ```bash + git push --set-upstream origin feature/is-even + ``` + + > **Note:** As mentioned earlier, this is a one-time setup for this branch. After this, you can simply use `git push` for future updates. + +6. **Create a pull request**: Go to your fork on GitHub, click "Compare & pull request", add a title and description, and create the PR. + +7. **Review and update**: If you or the reviewers make changes to your PR through the GitHub UI, you need to update your local branch with those changes: + + + + ```bash + git pull origin feature/is-even # git pull also works + ``` + + Additionally, if new changes are added to the [upstream][git-remotes] `develop` branch, you can integrate them into your feature branch using rebase or merge: + + + + ```bash + git checkout develop + git pull --ff-only upstream develop # Update local develop first + git checkout feature/is-even + git rebase develop # or git merge develop + ``` + + Resolve any conflicts with the steps mentioned earlier, then continue the rebase: + + + + ```bash + git rebase --continue + ``` + + Finally, push your changes: + + + + ```bash + git push --force # Force push after rebasing + ``` + + > **Note:** Force pushing is required after rebasing because it rewrites history. This is safe as long as you're the only one working on the branch. If you want to avoid force pushing, use merge instead of rebase. + +8. **Repeat**: After resolving conflicts and updating your branch, you can continue making changes, committing, and pushing until your PR is ready to be merged. + ## Conclusion Congratulations! You now have all the essential Git commands to navigate your workflow smoothly while contributing to `stdlib`. Whether you're fixing a bug, adding a feature, or just getting started, this cheatsheet will help you stay organized and avoid common pitfalls. Keep practicing, stay curious, and enjoy the process. Happy coding! From d2f4685256945ad844a81a3da1f1d13e8bddc877 Mon Sep 17 00:00:00 2001 From: Karan Anand Date: Wed, 26 Mar 2025 18:31:50 -0700 Subject: [PATCH 5/7] docs: add other reference links --- type: pre_commit_static_analysis_report description: Results of running static analysis checks when committing changes. report: - task: lint_filenames status: passed - task: lint_editorconfig status: passed - task: lint_markdown status: passed - task: lint_package_json status: na - task: lint_repl_help status: na - task: lint_javascript_src status: na - task: lint_javascript_cli status: na - task: lint_javascript_examples status: na - task: lint_javascript_tests status: na - task: lint_javascript_benchmarks status: na - task: lint_python status: na - task: lint_r status: na - task: lint_c_src status: na - task: lint_c_examples status: na - task: lint_c_benchmarks status: na - task: lint_c_tests_fixtures status: na - task: lint_shell status: na - task: lint_typescript_declarations status: na - task: lint_typescript_tests status: na - task: lint_license_headers status: passed --- --- type: pre_push_report description: Results of running various checks prior to pushing changes. report: - task: run_javascript_examples status: na - task: run_c_examples status: na - task: run_cpp_examples status: na - task: run_javascript_readme_examples status: na - task: run_c_benchmarks status: na - task: run_cpp_benchmarks status: na - task: run_fortran_benchmarks status: na - task: run_javascript_benchmarks status: na - task: run_julia_benchmarks status: na - task: run_python_benchmarks status: na - task: run_r_benchmarks status: na - task: run_javascript_tests status: na --- --- docs/contributing/git_cheatsheet.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/contributing/git_cheatsheet.md b/docs/contributing/git_cheatsheet.md index 0718946f4066..09b7a5f3b32a 100644 --- a/docs/contributing/git_cheatsheet.md +++ b/docs/contributing/git_cheatsheet.md @@ -483,6 +483,11 @@ Congratulations! You now have all the essential Git commands to navigate your wo To get started with your first contribution, check out the [Contributing Guide][stdlib-contributing] and [Development Guide][stdlib-development]. If you have any further questions, feel free to join our [Gitter][stdlib-gitter] channel to connect with the community and get support. +## Other Links + +- [GitHub Education Cheat Sheet][github-edu] +- [GitHub Training Cheat Sheet][github-training] +
[stdlib-contributing]: https://github.com/stdlib-js/stdlib/blob/develop/CONTRIBUTING.md @@ -501,6 +506,10 @@ To get started with your first contribution, check out the [Contributing Guide][ [github-style-guide]: https://github.com/stdlib-js/stdlib/tree/develop/docs/style-guides/git#git-commit-messages +[github-edu]: https://education.github.com/git-cheat-sheet-education.pdf + +[github-training]: https://training.github.com/downloads/github-git-cheat-sheet.pdf +
From c1bf2a30f5952e82084b57b1c71bea7e345af897 Mon Sep 17 00:00:00 2001 From: Athan Date: Thu, 27 Mar 2025 02:23:06 -0700 Subject: [PATCH 6/7] style: remove fancy quote Signed-off-by: Athan --- docs/contributing/git_cheatsheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/git_cheatsheet.md b/docs/contributing/git_cheatsheet.md index 09b7a5f3b32a..e40b22077cbe 100644 --- a/docs/contributing/git_cheatsheet.md +++ b/docs/contributing/git_cheatsheet.md @@ -203,7 +203,7 @@ git checkout develop git reset --hard upstream/develop ``` -> **Warning:** This will delete any changes you made to `develop`. Make sure you don’t have important work in this branch before running this command. +> **Warning:** This will delete any changes you made to `develop`. Make sure you don't have important work in this branch before running this command. After updating `develop`, you can push it to your fork to keep everything in sync: From 4b7c8c46ed9fe1f2c2587d29e83f77c439de8e91 Mon Sep 17 00:00:00 2001 From: Athan Date: Thu, 27 Mar 2025 02:24:37 -0700 Subject: [PATCH 7/7] style: remove fancy quotes Signed-off-by: Athan --- docs/contributing/git_cheatsheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/git_cheatsheet.md b/docs/contributing/git_cheatsheet.md index e40b22077cbe..0c3700268100 100644 --- a/docs/contributing/git_cheatsheet.md +++ b/docs/contributing/git_cheatsheet.md @@ -368,7 +368,7 @@ We will consider the conflict in the `isEven` function above. Let's say you want > **Tip:** Many editors like VS Code highlight conflicts and even give you buttons to accept incoming or current changes. This can make resolving conflicts much easier. -Merge conflicts can be annoying, but they’re a natural part of working with others. Take your time, and don’t hesitate to ask for help if you're stuck. +Merge conflicts can be annoying, but they're a natural part of working with others. Take your time, and don't hesitate to ask for help if you're stuck. ## Example Workflow