chore: sync content to repo (#10127)

Co-authored-by: nilbuild <4921183+nilbuild@users.noreply.github.com>
2026-08-30 17:57:21 +08:00 · 2026-07-06 20:44:12 +02:00
parent c633ca88b1
commit 9eee43098c
111 changed files with 259 additions and 532 deletions
@@ -1,6 +1,6 @@
 # --hard
-
-With this option, both the HEAD pointer and the working directory's contents are updated to match the specified commit. Any changes made since then will be lost.
+ 
+`git reset --hard` moves the branch pointer to a specified commit and resets both the staging area and working directory to match it exactly. Any changes in commits after that point, as well as any uncommitted work, get permanently discarded. This is one of the more destructive Git commands, so it should be used carefully since undone changes can be difficult to recover.

 Visit the following resources to learn more:

@@ -1,5 +1,7 @@
 # --soft
+ 
+`git reset --soft` moves the branch pointer to a specified commit while leaving the staging area and working directory untouched. This means all changes from the undone commits remain staged, ready to be recommitted differently. It's useful for combining multiple commits into one without losing any changes.

-In this mode, only the HEAD pointer is moved to the specified commit. The files in your working directory are not modified, but they remain as they were when you started the reset.
+Visit the following resources to learn more:

 - [@official@--soft documentation](https://git-scm.com/docs/git-reset#Documentation/git-reset.txt---soft)
@@ -1,6 +1,6 @@
 # Branch Naming
-
-A well-defined branch naming convention is essential for maintaining a clean and organized Git workflow. It's recommended to use descriptive and meaningful names that clearly indicate the purpose of each branch. For example, using prefixes like `feature/`, `fix/`, or `docs/` can help identify whether a branch is related to new feature development, bug fixes, or documentation updates. Additionally, including the issue or task ID (e.g., `issue/123`) can provide context and make it easier for team members to find relevant information. By following a consistent naming convention, you can improve collaboration, reduce confusion, and increase the overall efficiency of your Git workflow.
+ 
+Branch naming conventions give structure to how branches are labeled, often including a prefix like `feature/`, `bugfix/`, or `hotfix/` followed by a short description. Consistent naming makes it easy to identify a branch's purpose at a glance and helps automate workflows that trigger based on branch name patterns. Teams often document their convention in a contributing guide so everyone follows the same format.

 Visit the following resources to learn more:

@@ -6,4 +6,4 @@ Visit the following resources to learn more:

 - [@official@Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging)
 - [@article@Learn Git Branching](https://learngitbranching.js.org/)
- [@video@Git Branches Tutorial](https://www.youtube.com/watch?v=e2IbNHi4uCI)
+- [@video@Git Branches Tutorial](https://www.youtube.com/watch?v=e2IbNHi4uCI)
@@ -1,12 +1,6 @@
 # Caching Dependencies
-
-GitHub Actions provides a caching feature that allows you to store and reuse dependencies between workflows, reducing the time it takes to run your actions. By caching dependencies, you can:
-
- Reuse compiled code
- Store database connections
- Reduce network traffic
-
-It is highly recommended to not store any sensitive information in the cache. For example, sensitive information can include access tokens or login credentials stored in a file in the cache path.
+ 
+Caching dependencies in GitHub Actions stores files like package manager directories between workflow runs, avoiding the need to reinstall them from scratch every time. The `actions/cache` action saves and restores these files based on a key, often derived from a lockfile's hash. This significantly speeds up workflows that install the same dependencies repeatedly across multiple runs.

 Visit the following resources to learn more:

@@ -2,6 +2,6 @@

 The GitHub Campus Program offers GitHub Enterprise Cloud and GitHub Enterprise Server free-of-charge for schools that want to make the most of GitHub for their community. This program provides access to a comprehensive set of developer tools, as well as resources and support to help students and educators build projects, collaborate, and develop skills in software development.

-Visit the following resource to learn more:
+Visit the following resources to learn more:

 - [@official@About GitHub Campus Program](https://docs.github.com/en/education/explore-the-benefits-of-teaching-and-learning-with-github-education/use-github-at-your-educational-institution/about-github-campus-program)
@@ -1,11 +1,6 @@
 # Clean Git History
-
-Cleaning up Git history can make your commit history more readable, concise, and organized. Here are some of the reasons why you'd want to clean your git history:
-
- makes it easy to decipher the order of the commits in your repository
- It facilitates finding commits that might have introduced bugs and enable rollback if necessary
- To be able to deploy any commit on your development branch using your CI/CD system
- If you are handling mobile app releases and you are responsible for figuring out what feature is in which release.
+ 
+A clean Git history means commits are logically organized, well described, and free of unnecessary noise like "fix typo" or "WIP" messages. Techniques like squashing commits, rebasing, and writing clear commit messages all contribute to keeping history readable. A clean history makes it easier to trace when and why a specific change was introduced.

 Visit the following resources to learn more:

@@ -7,4 +7,4 @@ Visit the following resources to learn more:
 - [@official@git clone](https://git-scm.com/docs/git-clone)
 - [@official@Cloning a Repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)
 - [@article@Clone a Git Repository](https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-clone)
- [@video@Cloning Remote Repository into local machine](https://youtu.be/xeQih8LVtZM?si=djlyTDpLNS0oyqQH)
+- [@video@Cloning Remote Repository into local machine](https://youtu.be/xeQih8LVtZM?si=djlyTDpLNS0oyqQH)
@@ -1,16 +1,8 @@
 # Code Reviews
-
-The purpose of a code review in software development is to help ensure that the code meets the organization’s standards and requirements, is of high quality, and is maintainable. In addition to identifying errors and bugs, code reviews also promote a culture of learning and collaboration among the development team.
-
-Some of the benefits of code reviews include:
-
- Increase code quality by identifying defects in the code and issues such as security vulnerabilities and performance problems—before developers merge the code into an upstream branch.
- Ensure compliance with organizational standards, regulations, and the team’s code style.
- Save time and money by detecting issues earlier in the software development process before they become more complex and expensive to fix.
- Boost collaboration, communication, and knowledge sharing among developers by providing a forum to discuss code and ask questions, share ideas and best practices, and learn from each other.
- Ensure that the code is maintainable by identifying any software maintenance issues and suggesting improvements.
+ 
+A code review is the process of examining proposed changes in a pull request before they get merged, checking for bugs, style issues, or design concerns. Reviewers can leave comments on specific lines, approve the changes, or request modifications before approval. Code reviews help catch problems early and share knowledge of the codebase across a team.

 Visit the following resources to learn more:

 - [@article@A practical guide for better, faster code reviews](https://github.com/mawrkus/pull-request-review-guide)
- [@article@How to improve code with code reviews](https://github.com/resources/articles/software-development/how-to-improve-code-with-code-reviews)
+- [@article@How to improve code with code reviews](https://github.com/resources/articles/software-development/how-to-improve-code-with-code-reviews)
@@ -4,5 +4,5 @@ In GitHub, collaborators and members refer to individuals who contribute to or h

 Visit the following resources to learn more:

- [@article@Inviting collaborators to a personal repository](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository)
- [@official@REST API endpoints for collaborators](https://docs.github.com/en/rest/collaborators/collaborators?apiVersion=2022-11-28)
+- [@official@REST API endpoints for collaborators](https://docs.github.com/en/rest/collaborators/collaborators?apiVersion=2022-11-28)
+- [@article@Inviting collaborators to a personal repository](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository)
@@ -6,6 +6,5 @@ Visit the following resources to learn more:

 - [@article@How to Write Better Git Commit Messages](https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/)
 - [@article@Writing good commit messages](https://www.theodinproject.com/lessons/foundations-commit-messages)
- [@article@How to Write Good Git Commit Messages like a pro](https://medium.com/front-end-weekly/how-to-write-good-git-commit-messages-like-a-pro-2c12f01569d9)
 - [@video@Write git commit messages like a PRO with Conventional Commits](https://youtu.be/OJqUWvmf4gg?si=Fgl3isZpP13jYXHP)
 - [@video@How to Make Actually Good Commits in Git](https://youtu.be/Dy5t_H2PRrk?si=0V-JEbqphpJX5OLl)
@@ -1,10 +1,10 @@
 # Committing Changes
-
-Committing changes in Git is a crucial part of version control, allowing you to save your progress and record a snapshot of your project's current state.
+ 
+Committing saves a snapshot of the staged changes to the repository's history, along with a message describing what was changed and why. Each commit gets a unique hash that identifies it and allows Git to track the exact state of the project at that point. Commits build the timeline that developers can browse, compare, or revert to later.

 Visit the following resources to learn more:

- [@official@How git commit works](https://github.com/git-guides/git-commit)
- [@article@Git commit](https://www.atlassian.com/git/tutorials/saving-changes/git-commit)
 - [@course@Staging Area (Interactive Lesson)](https://inter-git.com/lessons/adding-files-to-index)
 - [@course@Making a Commit (Interactive Lesson)](https://inter-git.com/lessons/making-a-commit)
+- [@official@How git commit works](https://github.com/git-guides/git-commit)
+- [@article@Git commit](https://www.atlassian.com/git/tutorials/saving-changes/git-commit)
@@ -1,6 +1,6 @@
 # Creating Account

-To get started with GitHub, you'll need to create a free personal account on GitHub.com and verify your email address. Every person who uses GitHub.com signs in to a personal account. Your personal account is your identity on GitHub.com and has a username and profile.
+To get started with GitHub, you'll need to create a free personal account on [GitHub.com](http://GitHub.com) and verify your email address. Every person who uses [GitHub.com](http://GitHub.com) signs in to a personal account. Your personal account is your identity on [GitHub.com](http://GitHub.com) and has a username and profile.

 Visit the following resources to learn more:

@@ -5,4 +5,4 @@ Creating a branch in Git is a fundamental part of working with version control,
 Visit the following resources to learn more:

 - [@official@Git branch documentation](https://git-scm.com/docs/git-branch)
- [@article@Git branch](https://www.atlassian.com/git/tutorials/using-branches)
+- [@article@Git branch](https://www.atlassian.com/git/tutorials/using-branches)
@@ -4,4 +4,4 @@ Creating a Git repository means setting up a system to track changes in your pro

 Visit the following resources to learn more:

- [@official@Quickstart for repositories - GitHub Docs](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories)
+- [@official@Quickstart for repositories - GitHub Docs](https://docs.github.com/en/repositories/creating-and-managing-repositories/quickstart-for-repositories)
@@ -1,6 +1,6 @@
 # Custom Domains

-On GitHub Pages, users can customize their site's URL by connecting a custom domain to their repository. This feature allows users to use their own domain name instead of the default GitHub.io subdomain, giving their site a more professional and personalized look.
+On GitHub Pages, users can customize their site's URL by connecting a custom domain to their repository. This feature allows users to use their own domain name instead of the default [GitHub.io](http://GitHub.io) subdomain, giving their site a more professional and personalized look.

 Visit the following resources to learn more:

@@ -5,4 +5,4 @@ Deleting a Git branch means removing a line of development from your Git reposit
 Visit the following resources to learn more:

 - [@official@Creating and deleting branches within your repository](https://docs.github.com/articles/creating-and-deleting-branches-within-your-repository)
- [@article@How to Delete a Git Branch Both Locally and Remotely](https://www.freecodecamp.org/news/how-to-delete-a-git-branch-both-locally-and-remotely/)
+- [@article@How to Delete a Git Branch Both Locally and Remotely](https://www.freecodecamp.org/news/how-to-delete-a-git-branch-both-locally-and-remotely/)
@@ -4,5 +4,4 @@ Deploying static websites on GitHub Pages involves uploading and serving website

 Visit the following resources to learn more:

- [@article@How to Deploy a Static Website for Free Using GitHub Pages](https://medium.com/flycode/how-to-deploy-a-static-website-for-free-using-github-pages-8eddc194853b)
 - [@video@How to Host a Website on GitHub Pages Free (Custom Domain Setup Included)](https://www.youtube.com/watch?v=e5AwNU3Y2es)
@@ -1,6 +1,6 @@
 # Detached HEAD
-
-In Git, a detached head occurs when you check out a commit directly using its hash instead of a branch name. This leaves your repository's HEAD pointer pointing directly at that commit, rather than being linked to a specific branch. To view the history and changes made in a detached head, use `git log` or `git show`. If you want to see the differences between the current detached head and another branch, use `git diff <branch>`. A detached head can be a useful temporary state for exploring specific commits or features, but it's essential to merge those changes back into a branch before sharing them with others.
+ 
+A detached HEAD state occurs when HEAD points directly to a specific commit instead of a branch, typically after checking out a commit hash or tag. Any new commits made in this state aren't attached to a branch, so they can be lost once another branch is checked out unless a new branch is created to save them. This state is often used to inspect old commits without affecting the current branch.

 Visit the following resources to learn more:

@@ -1,15 +1,6 @@
 # Documentation
-
-A well-maintained repository should include documentation that helps others understand the project, its context, and how to contribute to it. This is essential for fostering a community around your project and making it easier for newcomers to join in.
-
-Here are some key sections of documentation that you should consider including in each repository:
-
- README.md: A brief introduction to the project, explaining what it's about, why it exists, and how to get started.
- CONTRIBUTING.md: Guidelines on how others can contribute to the project, including steps for reporting issues, submitting pull requests, or suggesting new features.
- LICENSE: Information about the license under which the repository is released, ensuring users understand their rights and responsibilities when using your code.
- CHANGELOG: A history of changes made to the project over time, highlighting significant updates, bug fixes, or feature additions.
-
-These documents help ensure a smooth onboarding process for contributors, making it easier for them to collaborate effectively and enhance the overall project.
+ 
+Documentation covers the written materials that explain how a project works, how to use it, and how to contribute to it. This includes README files, wikis, and citation files, all of which help users and contributors understand a repository without needing to read through all the source code. Good documentation is often what determines whether an open source project gets adopted or contributed to.

 Visit the following resources to learn more:

@@ -1,16 +1,10 @@
 # Fast-Forward vs Non-FF
-
-In Git, when you merge branches, there are two primary types of merges: Fast-Forward and Non-Fast-Forward (No-FF). These terms describe how Git handles the history and pointers when merging branches. Understanding the difference between these two types of merges is crucial for managing your project's commit history effectively.
-
-A Fast-Forward merge occurs when the branch you are merging into (often main or master) has not diverged from the branch you are merging (often a feature branch). In other words, the commit history of the target branch is a strict subset of the branch being merged. In a Fast-Forward merge, Git simply moves the pointer of the target branch forward to the latest commit on the branch being merged.
-No new merge commit is created; the history is linear.
-
-A Non-Fast-Forward (No-FF) merge happens when the target branch has diverged from the branch being merged or when you explicitly choose to create a merge commit. In this case, Git creates a new commit that represents the merging of the two branches. Git creates a new merge commit that has two parent commits: one from the target branch and one from the branch being merged. The merge commit is a snapshot of the merged work, preserving the history of both branches.
+ 
+A fast-forward merge happens when the target branch has no new commits since the feature branch was created, so Git simply moves the branch pointer forward without creating a new commit. A non-fast-forward merge occurs when both branches have diverged, requiring Git to create a dedicated merge commit that ties the two histories together. Developers can force a merge commit even when a fast-forward is possible by using `git merge --no-ff`, which some teams prefer for a clearer history.

 Visit the following resources to learn more:

 - [@article@Git Fast-Forward VS Non-Fast-Forward](https://leimao.github.io/blog/Git-Fast-Forward-VS-Non-Fast-Forward/)
- [@article@Git Merge: To Squash Or Fast-Forward?](https://dev.to/trpricesoftware/git-merge-to-squash-or-fast-forward-3791)
 - [@article@Difference between a git fast forward and no fast forward](https://gist.github.com/moraisaugusto/1fa02c49b6d9833fcdf665505595ac2e)
 - [@video@GIT Fast Forward Visualized](https://youtu.be/DN1fNYoJgDw?si=_TZKACj4SCOuESGm)
- [@video@git merge no fast forward](https://youtu.be/X_8atqzsO8U?si=e9hMQg_aWLRMWf4O)
+- [@video@git merge no fast forward](https://youtu.be/X_8atqzsO8U?si=e9hMQg_aWLRMWf4O)
@@ -1,6 +1,6 @@
 # Fetch without Merge
-
-Running `git fetch` retrieves changes from a remote repository into your local clone, but does not automatically merge any of these changes into your local working directory. This is different from `git pull`, which both fetches and merges remote changes. By using fetch without merge, you can ensure that your local clone is up-to-date with the latest information from the remote repository, while leaving your working directory unchanged. You can then choose to apply these changes by using merge or rebase. This approach helps maintain a clean and consistent local state, making it easier to manage and commit changes.
+ 
+`git fetch` downloads new commits, branches, and tags from a remote repository without merging them into the local branch. It updates the remote-tracking branches, like `origin/main`, so the developer can inspect incoming changes before deciding to merge or rebase them. This makes fetch a safer way to check for updates compared to `git pull`, which fetches and merges in one step.

 Visit the following resources to learn more:

@@ -1,8 +1,6 @@
 # Forking vs Cloning
-
-Forking and cloning are two fundamental concepts in Git, particularly when working with repositories hosted on platforms like GitHub, GitLab, or Bitbucket. While both actions involve copying a repository, they serve different purposes and have distinct workflows.
-Cloning a repository means creating a local copy of a repository that exists on a remote server (e.g., GitHub) on your local machine. This allows you to work on the project locally, make changes, and then push those changes back to the remote repository if you have the necessary permissions.
-Forking a repository is specific to platforms like GitHub, GitLab, and Bitbucket. When you fork a repository, you create a copy of someone else’s repository in your own account. This forked repository is independent of the original and can be modified without affecting the original project.
+ 
+Forking creates a personal copy of someone else's repository under the user's own GitHub account, allowing changes without affecting the original project. Cloning downloads a copy of a repository, whether it's the original or a fork, to a local machine for editing. Contributors typically fork a repository first, then clone their fork locally, so changes can eventually be proposed back to the original project through a pull request.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # Git Attributes

-Git attributes are settings stored in the .gitattributes file, controlling how Git handles files in your repository. They can influence filtering (e.g., ignoring specific files), conversion (formatting or transforming files during Git operations), and formatting (applying consistent styles). These settings can be applied to specific file types (like *.txt) or filter files based on content patterns. Attributes also define smudge patterns (highlighting differences) and ignore patterns, helping maintain a clean repository by automatically applying intended settings for certain file types.
+Git attributes are settings stored in the .gitattributes file, controlling how Git handles files in your repository. They can influence filtering (e.g., ignoring specific files), conversion (formatting or transforming files during Git operations), and formatting (applying consistent styles). These settings can be applied to specific file types (like \*.txt) or filter files based on content patterns. Attributes also define smudge patterns (highlighting differences) and ignore patterns, helping maintain a clean repository by automatically applying intended settings for certain file types.

 Visit the following resources to learn more:

@@ -5,5 +5,5 @@ Git Bisect is an interactive tool used to identify which commit in your project'
 Visit the following resources to learn more:

 - [@official@Git Bisect](https://git-scm.com/docs/git-bisect)
- [@article@Using `git bisect` to find the faulty commit](https://dev.to/alvesjessica/using-git-bisect-to-find-the-faulty-commit-25gf)
+- [@article@Using git bisect to find the faulty commit](https://dev.to/alvesjessica/using-git-bisect-to-find-the-faulty-commit-25gf)
 - [@video@Git Bisect | How to use Git Bisect | Learn Git](https://www.youtube.com/watch?v=z-AkSXDqodc)
@@ -1,12 +1,10 @@
-# git config
-
-The `git config` command is a convenience function that is used to set Git configuration values on a global or local project level. These configuration levels correspond to .gitconfig text files. Executing `git config` will modify a configuration text file.
-
-The most basic use case for `git config` is to invoke it with a configuration name, which will display the set value at that name. Configuration names are dot delimited strings composed of a 'section' and a 'key' based on their hierarchy. For example: `user.email`
-
-Visit the following resources to learn more:
-
- [@official@Git - git-config Documentation](https://git-scm.com/docs/git-config)
- [@article@git config | Atlassian Git Tutorial](https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-config)
- [@article@Setting your username in Git](https://docs.github.com/en/get-started/getting-started-with-git/setting-your-username-in-git)
+# git config
+ 
+`git config` sets configuration values that control how Git behaves, such as the user's name, email, and default editor. These settings can apply at different levels: system-wide, per user, or per repository. Git attaches this information to every commit, which is why setting a name and email is one of the first steps after installing Git.
+
+Visit the following resources to learn more:
+
+- [@official@Git - git-config Documentation](https://git-scm.com/docs/git-config)
+- [@article@git config | Atlassian Git Tutorial](https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-config)
+- [@article@Setting your username in Git](https://docs.github.com/en/get-started/getting-started-with-git/setting-your-username-in-git)
 - [@article@Git config commands | Git tutorial](https://nulab.com/learn/software-development/git-tutorial/git-commands-settings/git-config-commands/)
@@ -1,12 +1,6 @@
 # git filter-branch
-
-You can use `git filter-branch` to rewrite Git revision history by applying custom filters on each revision.
-
- Filter types: You can modify trees (e.g., removing a file or running a Perl script) or information about each commit.
- Preserving original data: The command preserves all original commit times, merge information, and other details unless specified otherwise.
- Rewriting specific branches: Only the positive refs mentioned in the command line are rewritten; if no filters are specified, commits are recommitted without changes.
-
-Notably, there exists a simpler, safer, and more powerful alternative: `git filter-repo`. This tool is actively promoted by Git and offers a streamlined approach to filtering revisions, making it a preferred choice for rewriting your Git history, especially when managing large repositories.
+ 
+`git filter-branch` rewrites a large portion of a repository's history, often used to remove sensitive files or restructure the project after the fact. It applies a filter across many or all commits, such as deleting a specific file from every point in history. Because it's slow and error-prone, Git's documentation now recommends the `git filter-repo` tool as a faster, safer alternative for the same kind of history rewriting.

 Visit the following resources to learn more:

@@ -1,11 +1,6 @@
 # Git hooks
-
-Git hooks are scripts that run automatically at specific points during the Git workflow, such as when you commit, push, or pull changes from a repository. These scripts can be used to perform various tasks, like validating code, formatting files, or even sending notifications.
-
-There are two types of Git hooks:
-
- Client-side hooks: Run on your local machine before committing changes.
- Server-side hooks: Run on the remote server when you push changes.
+ 
+Git hooks are scripts that run automatically at specific points in the Git workflow, such as before a commit or after a push. They live in the `.git/hooks` directory and can be written in any scripting language the system supports. Hooks are commonly used to enforce rules, like running tests before allowing a commit, or triggering actions like deployments after a push.

 Visit the following resources to learn more:

@@ -1,9 +1,9 @@
-# git init
-
-The `git init` command creates a new Git repository. It can be used to convert an existing, unversioned project to a Git repository or initialize a new, empty repository. Most other Git commands are not available outside of an initialized repository, so this is usually the first command you'll run in a new project.
-
-Visit the following resources to learn more:
-
- [@official@Git - git-init Documentation](https://git-scm.com/docs/git-init)
- [@article@git init | Atlassian Git Tutorial](https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-init#:~:text=The%20git%20init%20command%20creates,run%20in%20a%20new%20project.)
- [@course@Creating Repository (Interactive Lesson)](https://inter-git.com/lessons/creating-repository)
+# git init
+
+The `git init` command creates a new Git repository. It can be used to convert an existing, unversioned project to a Git repository or initialize a new, empty repository. Most other Git commands are not available outside of an initialized repository, so this is usually the first command you'll run in a new project.
+
+Visit the following resources to learn more:
+
+- [@course@Creating Repository (Interactive Lesson)](https://inter-git.com/lessons/creating-repository)
+- [@official@Git - git-init Documentation](https://git-scm.com/docs/git-init)
+- [@article@git init | Atlassian Git Tutorial](https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-init#:~:text=The%20git%20init%20command%20creates,run%20in%20a%20new%20project.)
@@ -1,23 +1,8 @@
 # git log options
-
-`git log` is a command in Git that shows the commit history of your repository. It provides a detailed view of all commits, including their hashes, authors, dates, and messages.
-
-Here are some common git log options:
-
- `-2`: Only show the last two commits.
- `-- <file-name>`: Show the commits that modified a specific file.
- `--all`: Show all branches in the repository.
- `--graph`: Display the commit history as a graph.
- `--pretty`: Enable clean colorized output.
- `--no-color`: Disable colorized output.
- `--stat`: Show a statistical summary of changes.
- `**-S`: Only show commits with modified files.
-
-You can combine these options to tailor your log output to suit your needs.
-
-For example, `git log -2 --graph` will display the last two commits in graph form.
+ 
+`git log` accepts many options to customize how commit history is displayed, such as `--oneline` for a condensed view or `--graph` to visualize branching and merging. Filters like `--author` or `--since` narrow results to specific contributors or time ranges. These options make it easier to search through large histories for exactly the information needed.

 Visit the following resources to learn more:

 - [@official@Git Log](https://git-scm.com/docs/git-log)
- [@article@Git Log Cheatsheet](https://elijahmanor.com/blog/git-log)
+- [@article@Git Log Cheatsheet](https://elijahmanor.com/blog/git-log)
@@ -1,6 +1,6 @@
 # git push --force
-
-`git push --force` is a command that allows you to overwrite or "force" an existing commit on a remote repository with a new commit from your local repository. This can be useful in certain situations, such as when you need to update the remote branch with changes that were previously rejected or when you want to remove commits that are no longer relevant. However, it's essential to exercise caution when using git push --force because it can overwrite changes made by others or even your own previous work. Always verify that there are no conflicting changes on the remote repository before using this command.
+ 
+`git push --force` overwrites the remote branch's history with the local branch's history, even if they've diverged. This is necessary after rewriting local commits, like through a rebase, since a normal push would be rejected due to mismatched history. Because it can overwrite others' work on a shared branch, `git push --force-with-lease` is often recommended instead, since it fails if the remote has changes the local branch doesn't know about.

 Visit the following resources to learn more:

@@ -6,5 +6,5 @@ Visit the following resources to learn more:

 - [@official@Git - git-rebase Documentation](https://git-scm.com/docs/git-rebase)
 - [@article@git rebase](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase)
- [@video@git rebase - Why, When &amp; How to fix conflicts](https://youtu.be/DkWDHzmMvyg?si=59jauQgkL-sMewzo)
+- [@video@git rebase - Why, When & How to fix conflicts](https://youtu.be/DkWDHzmMvyg?si=59jauQgkL-sMewzo)
 - [@video@Git Rebase --interactive: EXPLAINED](https://youtu.be/H7RFt0Pxxp8?si=gLhfkVW_PmWHBQSs)
@@ -1,8 +1,8 @@
 # Git Remotes
-
-In Git, a remote is a reference to a repository that exists on another server or system. Remotes allow you to access and interact with a copy of your repository that is stored elsewhere, making it possible to collaborate with others, share your work, and maintain multiple copies of your repository for backup and disaster recovery purposes. When you add a remote to your local repository, Git creates a reference to the remote repository, enabling you to push changes from your local repository to the remote one, pull changes from the remote to your local one, or fetch changes from the remote without updating your local copy. This enables distributed development and helps maintain a centralized version of your project's history, making it easier to track changes, manage conflicts, and ensure that everyone has access to the most up-to-date code.
+ 
+A remote is a version of a repository hosted somewhere other than the local machine, such as on GitHub. Remotes let developers push their local commits to a shared location and pull down changes made by others. A repository can have multiple remotes, though most projects use a single one, conventionally named `origin`.

 Visit the following resources to learn more:

 - [@official@About Remote Repositories](https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories)
- [@video@What is a Remote Repository? [Beginner Git Tutorial]](https://www.youtube.com/watch?v=Lb4yvfrX_7I)
+- [@video@What is a Remote Repository? \[Beginner Git Tutorial\]](https://www.youtube.com/watch?v=Lb4yvfrX_7I)
@@ -1,12 +1,6 @@
 # git revert
-
-Git revert is a command that allows you to "undo" or revert specific commits in your Git repository. It creates a new commit that reverses the changes made by the specified commit(s), effectively rolling back your code to a previous state.
-
-Here are some key things to know about `git revert`:
-
- Reverts changes, not moves HEAD: Unlike `git reset`, which can move your current branch's head to a different point in history, `git revert` creates new commits that reverse the changes made by specific commit(s).
- Creates new commits: Each time you use `git revert`, it creates a new commit that undoes the specified change. This means your Git history will still contain all previous commits.
- Can be used with multiple commits: If you want to revert multiple commits, simply specify their hashes or references (e.g., branch names) separated by commas.
+ 
+`git revert` creates a new commit that undoes the changes made by a previous commit, without altering existing history. This makes it a safe way to undo changes on a branch that others have already pulled, since it doesn't rewrite any commits. Running `git revert <commit-hash>` applies the inverse of that commit's changes and prompts for a new commit message.

 Visit the following resources to learn more:

@@ -1,12 +1,6 @@
 # Git Stash Basics
-
-Git stash allows you to temporarily save your changes, or "stashes", when they're not yet ready for commit. This feature is useful when you need to work on multiple tasks, and want to switch between them without committing changes that are not complete. By using `git stash`, you can quickly stash uncommitted changes, reset the working directory to a clean state, and then apply the stashed changes later when they're ready for commit. This helps avoid cluttering the commit history with incomplete work, and allows you to maintain a clean and organized repository by separating your progress on different tasks.
-
-To apply a stash in Git, you can use the following commands:
-
- `git stash apply`: This command applies the topmost stash (the most recent one) by default. It will merge the stashed changes into your current working directory.
- `git stash apply <stash_name>`: If you want to specify a particular stash, you can use its name instead of default. For example, if you've stored multiple stashes and want to apply an earlier one, you can use <stash_name>.
- `git stash pop`: This command is similar to apply, but it also automatically deletes the applied stash from the stash list. If you need more control over which stash to apply, using pop might be a better option.
+ 
+Git stash temporarily saves uncommitted changes so the working directory can be cleaned without committing incomplete work. The command `git stash` saves the current changes and reverts the working directory to match the last commit, while `git stash pop` restores them later. This is useful when a developer needs to quickly switch branches or pull updates without losing in-progress work.

 Visit the following resources to learn more:

@@ -1,11 +1,6 @@
 # Git vs Other VCS
-
-Git has become the de facto standard for source control in software development, but it's not the only version control system (VCS) available. Here are some key differences between Git and other popular VCS:
-
- Mercurial: Mercurial is a distributed VCS that uses a similar architecture to Git. However, it has a more centralized approach and doesn't use hashes for tracking changes.
- Subversion: Subversion is a centralized VCS that's often compared to Git. While both systems support branching and merging, Subversion requires a central server to manage the repository.
- Perforce: Perforce is a commercial VCS that's designed for large-scale development projects. It uses a centralized approach and has features like build automation and issue tracking.
- CVS: CVS is an older version control system that's still in use today. However, it lacks many modern features and is often considered outdated.
+ 
+Git is a distributed version control system, meaning every developer has a full copy of the project history on their own machine, not just the latest snapshot. Older systems like Subversion (SVN) or CVS are centralized, so they depend on a single server for most operations and require a network connection to commit changes. Git allows commits, branching, and history browsing to happen offline, and syncing with a remote server happens only when pushing or pulling.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # Git Worktree
-
-A Git worktree allows you to create multiple working directories for a single repository, each with its own checkout and index. Unlike a regular checkout, which creates a new working directory for a specific branch and updates your IDE's configuration settings, a Git worktree does not require you to switch between branches using git checkout. This means you can have multiple branches checked out at the same time without affecting each other or requiring changes to your IDE configurations. By creating a separate worktree for each branch, you can stage changes independently and maintain distinct working directories without impacting the main repository or its working directory.
+ 
+Git worktree allows multiple branches to be checked out simultaneously in separate directories, all linked to the same repository. Running `git worktree add <path> <branch>` creates a new working directory for a specific branch without needing to clone the repository again. This is useful when a developer needs to work on two branches at once, like testing a hotfix while a feature branch remains checked out elsewhere.

 Visit the following resources to learn more:

@@ -1,12 +1,10 @@
 # GitHub Actions
-
-GitHub Actions is a very useful tool for automation, allowing developers to automate tasks within the software development lifecycle directly on GitHub.
-
-One of the best ways to learn about GitHub Actions is through the course offered by Microsoft Learn. This course is well-structured and provides practical examples that are concise and easy to understand.
+ 
+GitHub Actions is a CI/CD platform built into GitHub that automates tasks like testing, building, and deploying code in response to repository events. Workflows are defined in YAML files stored in the `.github/workflows` directory and can run on GitHub-hosted or self-hosted runners. It's widely used to automate everything from running test suites on every pull request to deploying applications after a merge.

 Visit the following resources to learn more:

- [@official@GitHub Actions](https://docs.github.com/en/actions)
 - [@course@Microsoft Learn: Introduction to GitHub Actions](https://learn.microsoft.com/en-us/collections/n5p4a5z7keznp5)
 - [@course@YouTube: GitHub Actions Playlist](https://www.youtube.com/watch?v=-hVG9z0fCac&list=PLArH6NjfKsUhvGHrpag7SuPumMzQRhUKY&pp=iAQB)
+- [@official@GitHub Actions](https://docs.github.com/en/actions)
 - [@video@What are GitHub Actions](https://www.youtube.com/watch?v=URmeTqglS58)
@@ -1,8 +1,8 @@
 # GitHub CLI
-
-GitHub CLI is a command-line interface tool that brings GitHub functionality to your terminal. It allows developers to interact with GitHub directly from the command line, enabling them to manage repositories, create issues, pull requests, and perform various GitHub operations without leaving their terminal environment. This powerful tool streamlines workflows, enhances productivity, and provides a seamless integration between local development and GitHub's collaborative features, making it easier for developers to incorporate GitHub into their daily coding routines.
+ 
+GitHub CLI, or `gh`, is a command-line tool that lets developers interact with GitHub directly from the terminal instead of the web interface. It supports common tasks like creating repositories, managing issues, and opening pull requests without switching context. Being scriptable also makes it useful for automating GitHub-related tasks in scripts or CI pipelines.

 Visit the following resources to learn more:

 - [@official@GitHub CLI Docs](https://cli.github.com/)
- [@video@What is the GitHub CLI?](https://www.youtube.com/watch?v=uy_PEGgUF4U)
+- [@video@What is the GitHub CLI?](https://www.youtube.com/watch?v=uy_PEGgUF4U)
@@ -1,6 +1,6 @@
 # GitHub Codespaces
-
-GitHub Codespaces is a cloud-based development environment that allows developers to create, access, and use pre-configured, ready-to-use environments for coding. It provides a seamless way to develop, test, and debug applications in a virtual machine or container, eliminating the need for local setup and configuration. With GitHub Codespaces, users can spin up a new environment with their desired configuration, tools, and dependencies in just a few clicks. This feature streamlines development workflows, reduces friction, and increases productivity by providing instant access to a tailored coding environment for each project.
+ 
+GitHub Codespaces provides a cloud-based development environment that can be launched directly from a repository, complete with a configured editor and terminal. It uses a configuration file, typically a `devcontainer.json`, to define the environment's tools, extensions, and dependencies. This lets developers start coding immediately in a consistent setup without needing to install anything locally.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # GitHub Discussions
-
-GitHub Discussions is a collaborative communication feature within GitHub repositories that provides a dedicated space for community conversations, questions, and knowledge sharing. It allows team members, contributors, and users to engage in threaded discussions, share ideas, ask for help, and make announcements outside of specific code changes or issues. This feature enhances project collaboration by centralizing important conversations, reducing noise in the issue tracker, and fostering a sense of community around open-source projects or team initiatives.
+ 
+GitHub Discussions is a forum-style feature for conversations that don't fit the structure of an issue, such as general questions, ideas, or announcements. Unlike issues, discussions aren't meant to track specific tasks and can be organized into categories like Q&A or ideas. Maintainers often enable discussions to separate open-ended community conversation from actionable bug reports.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # GitHub Essentials
-
-GitHub Essentials refers to the core features and functionalities that form the foundation of GitHub's version control and collaboration platform. These essentials include repositories for storing and managing code, branches for parallel development, pull requests for code review and merging, issues for tracking tasks and bugs, and collaborative tools like project boards and wikis. Understanding and mastering these fundamental components allows developers to effectively manage their projects, collaborate with team members, and contribute to open-source initiatives, making GitHub an indispensable tool in modern software development workflows.
+ 
+GitHub Essentials covers the core features needed to start using GitHub as a collaboration platform on top of Git. This includes creating an account, understanding the interface, setting up a profile, and creating repositories. These basics form the starting point for hosting projects online and working with other developers.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # GitHub Interface
-
-The GitHub interface is a web-based platform that provides a user-friendly environment for managing and collaborating on software projects. It offers a comprehensive set of tools and features accessible through an intuitive layout, including repository management, code browsing, issue tracking, pull requests, and project boards. The interface is designed to streamline workflows, facilitate team communication, and enhance productivity for developers of all skill levels. With its clean and organized structure, users can easily navigate between different sections of their projects, review code changes, manage tasks, and interact with team members, making it an essential tool for modern software development and version control.
+ 
+The GitHub interface is the web-based dashboard used to navigate repositories, pull requests, issues, and account settings. It includes a repository view showing files and commit history, a notifications tab, and organization or team pages for shared projects. Learning the layout helps developers find their way around features like code review, project boards, and settings without confusion.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # GitHub Organizations
-
-GitHub Organizations are shared accounts that provide centralized management and collaboration for multiple projects and teams. They offer enhanced administrative controls, allowing owners to create teams with specific access permissions, manage member roles, and oversee repositories at scale. Organizations facilitate better project coordination, resource sharing, and team communication, making them ideal for businesses, open-source projects, and large-scale collaborations. With features like team discussions, project boards, and audit logs, GitHub Organizations streamline workflow management and foster a more structured and secure development environment.
+ 
+A GitHub organization is a shared account used by companies or groups to manage multiple repositories, members, and teams under one umbrella. It allows centralized billing, permission management, and visibility settings across all repositories owned by the organization. Organizations are commonly used instead of personal accounts when multiple people need structured, ongoing access to a set of projects.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # GitHub Packages
-
-GitHub Packages is a package repository service that allows developers to store and share packages, containers, and other software artifacts. It provides a central location for sharing packages with teams, organizations, or the wider developer community. GitHub Packages supports popular package managers like npm, Maven, and Gradle, as well as container registries like Docker Hub. This feature enables seamless integration of packages into development workflows, making it easier to share dependencies, libraries, and frameworks within and across projects. By using GitHub Packages, developers can simplify dependency management, reduce errors, and improve overall collaboration.
+ 
+GitHub Packages is a package hosting service that lets developers publish and manage packages, like npm, Docker, or Maven artifacts, directly within GitHub. It integrates with existing repository permissions, so access to a package can follow the same rules as the repository it's tied to. Teams use it to keep both their code and its published packages within the same platform and permission system.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # GitHub Projects
-
-GitHub Projects is a flexible project management tool integrated directly into GitHub repositories. It allows teams to create customizable project boards, track issues and pull requests, and manage workflows using Kanban-style columns or table views. With features like automated workflows, custom fields, and various visualization options, GitHub Projects helps teams organize, prioritize, and track work across multiple repositories. This tool enhances collaboration, increases transparency, and streamlines project management processes, making it easier for developers and stakeholders to stay aligned on project goals and progress.
+ 
+GitHub Projects is a built-in project management tool that lets teams organize issues and pull requests into boards, tables, or timelines. It supports custom fields, automation rules, and different views to track work across one or multiple repositories. Teams use it to plan sprints, track progress, and visualize the status of ongoing work without leaving GitHub.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # GitHub Releases
-
-GitHub Releases is a feature that allows developers to package and distribute software versions to users. It provides a way to create tagged points in a repository's history, attach binary files (such as compiled executables or packaged code), and include release notes. This feature makes it easy to track and manage different versions of a project, share pre-compiled binaries with users who may not want to build from source, and communicate changes and updates to the community. GitHub Releases integrates seamlessly with Git tags and can be automated as part of a continuous integration and deployment pipeline.
+ 
+A GitHub release packages a specific tag along with release notes, binaries, or other downloadable assets. It gives users a clear, versioned snapshot of the project they can download without cloning the entire repository. Releases are commonly used to distribute compiled software, mark milestones, and document what changed between versions.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # GitHub Security
-
-GitHub Security is a suite of features and tools that help developers identify, fix, and prevent security vulnerabilities in their code. It provides a comprehensive approach to secure coding practices by integrating with the developer's workflow. The main components of GitHub Security include: `Code Scanning`, which uses AI-powered analysis to detect potential vulnerabilities; `Dependabot`, which automates dependency updates to prevent attacks via vulnerable dependencies; `Secret scanning`, which detects and flags secrets like API keys or credentials; and `GitHub Advanced Security`, which offers more advanced security features for larger teams. By using these tools, developers can ensure their code is secure, and identify potential issues before they become serious problems.
+ 
+GitHub Security covers the built-in tools that help identify and fix vulnerabilities in a repository, such as dependency scanning, secret scanning, and code scanning. These features can flag outdated dependencies with known vulnerabilities or detect accidentally committed secrets like API keys. Security features can be enabled from the repository settings and often integrate directly with pull requests to flag issues before they get merged.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # GitHub Sponsors
-
-A GitHub Sponsor is a way to support and fund open-source projects on GitHub. It allows maintainers of public repositories to receive financial support from users who value their work. Sponsors can contribute funds to help with expenses, development time, or other project-related costs. In return, sponsors are recognized as supporters in the repository's README file and on the project's website. This feature promotes transparency, accountability, and appreciation within open-source communities, making it easier for maintainers to focus on their projects.
+ 
+GitHub Sponsors lets developers and organizations receive financial support directly from users who want to fund their open source work. Sponsors can choose a one-time or recurring monthly contribution, and maintainers can offer different sponsorship tiers with specific perks. This gives open source maintainers a way to earn income for their work directly through the platform.

 Visit the following resources to learn more:

@@ -1,8 +1,8 @@
 # GitHub Wikis
-
-GitHub Wikis are collaborative documentation spaces integrated directly into GitHub repositories. They provide a platform for teams to create, edit, and organize project-related information, such as documentation, guidelines, and FAQs. Wikis support Markdown formatting, making it easy to structure content and include images or links. With version control and the ability to clone wiki repositories, teams can collaboratively maintain up-to-date documentation alongside their code, enhancing project understanding and facilitating knowledge sharing among contributors and users.
+ 
+A GitHub wiki is a separate space attached to a repository for writing longer-form documentation, tutorials, or notes that don't belong in the main README. Wikis support Markdown and have their own version history, similar to the main repository. They're often used for detailed guides, FAQs, or design documents that would otherwise clutter the codebase.

 Visit the following resources to learn more:

 - [@official@About Wikis](https://docs.github.com/en/communities/documenting-your-project-with-wikis/about-wikis)
- [@official@Documenting your project with Wikis](https://docs.github.com/en/communities/documenting-your-project-with-wikis)
+- [@official@Documenting your project with Wikis](https://docs.github.com/en/communities/documenting-your-project-with-wikis)
@@ -1,10 +1,10 @@
-# .gitignore
-
-Ignored files are tracked in a special file named `.gitignore` that is checked in at the root of your repository. There is no explicit git ignore command: instead the `.gitignore` file must be edited and committed by hand when you have new files that you wish to ignore. `.gitignore` files contain patterns that are matched against file names in your repository to determine whether or not they should be ignored.
-
-Visit the following resources to learn more:
-
- [@official@gitignore Documentation](https://git-scm.com/docs/gitignore)
- [@article@.gitignore file - ignoring files in Git | Atlassian Git Tutorial](https://www.atlassian.com/git/tutorials/saving-changes/gitignore)
- [@article@Ignoring files - GitHub Docs](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files)
- [@opensource@gitignore - A collection of useful .gitignore templates](https://github.com/github/gitignore)
+# .gitignore
+
+Ignored files are tracked in a special file named `.gitignore` that is checked in at the root of your repository. There is no explicit git ignore command: instead the `.gitignore` file must be edited and committed by hand when you have new files that you wish to ignore. `.gitignore` files contain patterns that are matched against file names in your repository to determine whether or not they should be ignored.
+
+Visit the following resources to learn more:
+
+- [@official@gitignore Documentation](https://git-scm.com/docs/gitignore)
+- [@opensource@gitignore - A collection of useful .gitignore templates](https://github.com/github/gitignore)
+- [@article@.gitignore file - ignoring files in Git | Atlassian Git Tutorial](https://www.atlassian.com/git/tutorials/saving-changes/gitignore)
+- [@article@Ignoring files - GitHub Docs](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files)
@@ -4,5 +4,6 @@ The GitHub GraphQL API is a set of APIs that provides access to various GitHub f

 Visit the following resources to learn more:

+- [@roadmap@Visit the Dedicated GraphQL Roadmap](https://roadmap.sh/graphql)
 - [@official@GitHub GraphQL API documentation](https://docs.github.com/en/graphql)
 - [@official@Forming calls with GraphQL](https://docs.github.com/en/graphql/guides/forming-calls-with-graphql)
@@ -1,8 +1,6 @@
 # Installation and Setup
-
-The GitHub CLI can be installed on Windows, macOS, and Linux operating systems. Installation options include downloading binaries directly from the release page or using package managers (such as homebrew, pip, etc).
-
-Once installed, setting up the GitHub CLI typically involves authenticating with your GitHub account by running `gh auth login` in your terminal. This step is essential for linking your GitHub credentials to the CLI, allowing you to interact with your repositories and perform various actions.
+ 
+Installing GitHub CLI involves downloading the `gh` tool through a package manager like Homebrew, apt, or winget, depending on the operating system. After installation, running `gh auth login` connects the tool to a GitHub account through browser or token-based authentication. Once authenticated, `gh` commands can be run from any repository to interact with GitHub directly.

 Visit the following resources to learn more:

@@ -1,12 +1,6 @@
 # Installing Git Locally
-
-To use Git on your local machine, you need to install it first. The installation process varies depending on your operating system:
-
- On Windows: Download the binary from the official Git or GitHub release page and follow the installation instructions.
- On macOS (using Homebrew): Run `brew install git` in your terminal.
- On Linux: Run `sudo apt-get install git` or `sudo yum install git` depending on your distribution.
-
-Once installed, you can verify the Git version by running `git --version` in your terminal. This will display the currently installed Git version.
+ 
+Installing Git locally means setting up the Git command-line tool on a personal machine so it can track and manage code changes. The installation process differs by operating system: Windows users typically download an installer from the official Git website, macOS users can install it through Homebrew or Xcode command line tools, and Linux users install it through their package manager. Once installed, running `git --version` in a terminal confirms the setup worked.

 Visit the following resources to learn more:

@@ -1,12 +1,6 @@
 # Issue Management
-
-The GitHub CLI provides a range of features for managing issues within your repository. Here are some key actions you can perform:
-
- Listing issues: Run `gh issue list` to view a list of all open and closed issues.
- Creating issues: Use `gh issue create --title "Issue Title" --body "Issue body"` to create a new issue with the specified title and body.
- Assigning issues: Run `gh issue assign <issue-number> <username>` to assign an issue to a specific user.
- Labelling issues: Use `gh issue label <issue-number> <label-name>` to add a label to an existing issue.
- Closing issues: Run `gh issue close <issue-number>` to mark an issue as closed.
+ 
+GitHub CLI allows creating, listing, and closing issues directly from the terminal using commands like `gh issue create` and `gh issue list`. Filters can narrow results by label, assignee, or state, similar to searching issues on the website. This makes it possible to triage or manage issues without switching to a browser.

 Visit the following resources to learn more:

@@ -1,16 +1,6 @@
 # Issues
-
-On GitHub, an issue is a way to track and report bugs, feature requests, or other problems with a repository. Here are some key aspects of issues:
-
- Creating issues: Users can create new issues by submitting a form on the repository's Issues page.
- Issue titles and descriptions: Each issue has a title and body (description), which provide context for the problem or request.
- Assignees: Issues can be assigned to specific users, who are then responsible for addressing the issue.
- Labels: Labels are used to categorize issues by topic, priority, or other criteria. This helps filter and organize issues within a repository.
- States: Issues have states that reflect their status, such as "Open", "Closed", or "Pending".
- Comments: Users can comment on existing issues to discuss or provide additional context.
- Labels and milestones: Issues can be associated with labels (topics) and milestones (deadlines), which help filter and prioritize them.
-
-Issues are a core feature of GitHub repositories, enabling teams to collaborate effectively on resolving problems and implementing new features.
+ 
+Issues are used to track bugs, feature requests, or tasks related to a repository. Each issue has a title, description, and optional labels, assignees, and milestones, and it can be commented on to discuss the problem or proposed solution. Issues can be closed manually or automatically when a linked pull request that fixes them gets merged.

 Visit the following resources to learn more:

@@ -1,8 +1,6 @@
 # Kanban Boards
-
-On GitHub, Kanban boards provide a visual representation of issues as they move through the development process.
-
-A Kanban board typically has columns representing different stages or states, such as "To-Do", "In-Progress", and "Done". Each issue is represented by a card on the board, which can be moved between columns as its state changes. Users can drag and drop issue cards to move them from one column to another, reflecting progress or completion.
+ 
+A Kanban board is a visual layout that organizes tasks into columns representing different stages, such as "To Do," "In Progress," and "Done." Items move across columns as their status changes, giving a clear picture of the team's workflow at a glance. GitHub Projects supports this board view natively, letting issues and pull requests be dragged between columns.

 Visit the following resources to learn more:

@@ -1,13 +1,6 @@
 # Labelling Issues / PRs
-
-On GitHub, labels are a way to categorize issues and pull requests (PRs) by topic, priority, or other criteria. Some common labels used are:
-
- `Bug`
- `Duplicate`
- `Enhancement`
- `Feature request`
- `High priority`
- `Needs feedback`
+ 
+Labels are colored tags applied to issues and pull requests to categorize them by type, priority, or status. Common examples include "bug," "enhancement," or "help wanted," and repositories can define custom labels to match their workflow. Labels make it easier to filter and search through large numbers of issues or pull requests at a glance.

 Visit the following resources to learn more:

@@ -4,10 +4,7 @@ A Version Control System (VCS) is a tool that helps developers manage changes to

 Visit the following resources to learn more:

- [@article@What is version control?](https://www.atlassian.com/git/tutorials/what-is-version-control)
- [@article@What is Git? - The Complete Guide to Git](https://www.datacamp.com/blog/all-about-git)
- [@article@Version Control (Git) - The Missing Semester of Your CS Education](https://missing.csail.mit.edu/2020/version-control/)
- [@video@What is Git? Explained in 2 Minutes!](https://www.youtube.com/watch?v=2ReR1YJrNOM)
- [@official@GUI Clients](https://git-scm.com/downloads/guis)
 - [@official@Getting Started - Installing Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
 - [@official@Creating an account on GitHub](https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github)
+- [@article@What is version control?](https://www.atlassian.com/git/tutorials/what-is-version-control)
+- [@video@What is Git? Explained in 2 Minutes!](https://www.youtube.com/watch?v=2ReR1YJrNOM)
@@ -1,9 +1,6 @@
 # Linear vs Non-Linear
-
-In Git, linear and non-linear history refer to different ways of managing commit history.
-
- Linear history: A repository with a linear history has commits that are applied in a single, sequential order.
- Non-linear history: A repository with a non-linear history allows multiple branches or lines of development, which can be merged back into the main branch at different points.
+ 
+A linear history means commits follow a single, straight sequence with no branching or merging, often achieved through rebasing instead of merging. A non-linear history includes branches that diverge and later merge back together, creating a more complex graph of commits. Teams choose between the two based on whether they prioritize a simple, readable log or a history that reflects exactly how work happened in parallel.

 Visit the following resources to learn more:

@@ -1,9 +1,6 @@
 # Local vs Global Config
-
-To manage local and global configuration settings, you can use the git config command with the --local and --global options.
-
- Local configuration: Run `git config --local [key] [value]` to set a local configuration setting for the current repository.
- Global configuration: Use `git config --global [key] [value]` to set a global configuration setting that applies to all repositories on your system.
+ 
+Git configuration can be set at the local level, which applies only to the current repository, or at the global level, which applies to every repository for that user. Local settings are stored inside a repository's `.git/config` file and override global ones when both exist. Global settings live in a file in the user's home directory, and developers typically use them to set default identity information like name and email across all their projects.

 Visit the following resources to learn more:

@@ -1,13 +1,6 @@
 # Managing Remotes
-
-In Git, a remote repository refers to a copy of a project's source code stored on a server or other machine.
-
- Adding remotes: Use `git remote add [name] [url]` to add a new remote repository. This allows you to track changes and push/pull updates from the remote.
- Listing remotes: Run `git remote -v` to list all configured remotes with their URLs.
- Renaming remotes: Update the name of an existing remote using `git remote rename [old-name] [new-name]`.
- Deleting remotes: Remove a remote repository with `git remote remove [name]`.
-
-Managing remotes is essential for collaborating on projects or tracking changes from upstream sources.
+ 
+Managing remotes involves adding, renaming, or removing the remote repositories a local project is connected to. The command `git remote add <name> <url>` links a new remote, `git remote rename` changes its label, and `git remote remove` deletes the connection entirely. Running `git remote -v` lists all configured remotes along with their URLs.

 Visit the following resources to learn more:

@@ -1,12 +1,6 @@
 # Managing Tags
-
-In Git, a tag is a named reference to a specific commit in the project's history.
-
- Creating tags: Use `git tag [name] [commit-hash]` to create a new tag. You can also use `git tag -a [name] -m "[message]" [commit-hash]` for annotated tags.
- Listing tags: Run `git tag` to display all existing tags.
- Deleting tags: Remove an existing tag with `git tag -d [tag-name]`.
-
-Tags can be used for marking releases, milestones, or other significant events in a project's history.
+ 
+Managing tags involves creating, listing, and deleting tags within a repository. The command `git tag <name>` creates a lightweight tag, while `git tag -a <name> -m "message"` creates an annotated one with extra details. Running `git tag` alone lists existing tags, and `git tag -d <name>` deletes one locally.

 Visit the following resources to learn more:

@@ -1,12 +1,6 @@
 # Markdown
-
-Markdown is a simple way to add formatting to text without using HTML tags or other complex syntax. It's easy to read and write, making it suitable for documentation, README files, and more. Some basic GitHub Markdown features include:
-
- Basic syntax: Use headers (`# Heading`), bold/italic text (**bold**, *italic*), and lists (- item) to format text.
- Links: Create links with `[text](url)` or `[text][ref]`.
- Images: Embed images with `[![alt-text](image-url)]`.
-
-By using Markdown, you can easily format text within your GitHub repository, making it easier to read and understand for yourself and others.
+ 
+Markdown is a lightweight markup language used to format text with plain, readable syntax, like using asterisks for bold or a hash symbol for headings. GitHub renders Markdown automatically in README files, issues, pull requests, and comments, converting the plain text syntax into styled output. Its simplicity makes it a common choice for documentation across many platforms beyond just GitHub.

 Visit the following resources to learn more:

@@ -1,12 +1,6 @@
 # Marketplace Actions
-
-The GitHub Marketplace offers a wide range of pre-built actions that can be used to automate tasks and workflows within your repository.
-
- Automate tasks: Use marketplace actions to automate tasks such as testing, deployment, or security.
- Customize workflows: Create custom workflows using marketplace actions to tailor the build process to specific needs.
- Streamline development: By automating repetitive tasks, developers can focus on code quality and collaboration.
-
-These actions are created by the GitHub community and can be easily added to your workflow to enhance productivity and efficiency.
+ 
+Marketplace Actions are pre-built, reusable workflow steps published by GitHub and the community that can be added to any workflow. Instead of writing custom scripts for common tasks like checking out code or setting up a programming language, a workflow can reference an action like `actions/checkout` or `actions/setup-node`. Using marketplace actions saves time and lets workflows benefit from tools maintained and tested by others.

 Visit the following resources to learn more:

@@ -1,12 +1,6 @@
 # Merge Strategies
-
-When combining changes from one branch into another, Git provides various merge strategies to choose from. These methods allow for flexibility and customization in integrating code updates into your main branch. The available options include:
-
- Fast Forward (FF)
- Non-Fast Forward
- Rebase
- Squash
- Cherry Picking
+ 
+Merge strategies are the different approaches Git offers for combining changes from one branch into another. Options include a standard merge that preserves full history, a squash merge that condenses all commits into one, and a rebase that replays commits on top of another branch. Choosing a strategy affects how clean or detailed the resulting commit history looks.

 Visit the following resources to learn more:

@@ -5,4 +5,4 @@ GitHub OAuth Apps allow developers to integrate with GitHub using OAuth 2.0 auth
 Visit the following resources to learn more:

 - [@official@Creating an OAuth app](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app)
- [@video@GitHub Login With React (GitHub APIs, GitHub OAuth 2.0 Authentication)](https://www.youtube.com/watch?v=rRn2EisxPl4)
+- [@video@GitHub Login With React (GitHub APIs, GitHub OAuth 2.0 Authentication)](https://www.youtube.com/watch?v=rRn2EisxPl4)
@@ -1,8 +1,8 @@
 # PR from a Fork
-
-Creating a pull request from a fork on GitHub is a common workflow for contributing to open-source projects or collaborating on repositories you don't have direct write access to. After forking the original repository to your GitHub account, you can make changes in your fork, commit them, and then create a pull request to propose these changes to the original repository. This process allows project maintainers to review your contributions, discuss any necessary modifications, and ultimately merge your changes into the main project if they're approved. It's an essential feature that facilitates collaboration and code review in distributed development environments.
+ 
+A pull request from a fork lets a contributor propose changes to a repository they don't have write access to. The contributor forks the repository, makes changes on their own copy, and opens a pull request comparing their fork's branch against the original repository. This workflow is the standard way open source contributions happen, since it doesn't require granting outside contributors direct write access.

 Visit the following resources to learn more:

 - [@official@Creating a pull request from a fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork)
- [@video@How to Create a Pull Request from a Fork on GitHub](https://www.youtube.com/watch?v=a_FLqX3vGR4)
+- [@video@How to Create a Pull Request from a Fork on GitHub](https://www.youtube.com/watch?v=a_FLqX3vGR4)
@@ -1,6 +1,6 @@
 # PR Guidelines
-
-Pull Request (PR) guidelines are essential for maintaining a smooth and efficient code review process in collaborative development environments. These guidelines typically outline best practices for creating, formatting, and submitting PRs, ensuring that changes are well-documented, easy to review, and align with the project's standards. They may cover aspects such as PR size, commit message formatting, documentation requirements, and testing expectations. By establishing clear PR guidelines, teams can streamline their workflow, improve code quality, and facilitate effective communication among contributors.
+ 
+Pull request guidelines are the conventions a project sets for how contributions should be submitted, often documented in a `CONTRIBUTING.md` file. They typically cover expectations like keeping pull requests focused on a single change, writing a clear description, and linking related issues. Following these guidelines makes it easier for maintainers to review and merge contributions quickly.

 Visit the following resources to learn more:

@@ -1,8 +1,8 @@
 # pre-commit
-
-Git pre-commit hooks are scripts that run automatically before a commit is created, allowing developers to enforce code quality standards and catch issues early in the development process. These hooks can perform tasks such as linting, formatting, running tests, or checking for sensitive information, ensuring that only clean and compliant code is committed to the repository. By intercepting the commit process, pre-commit hooks help maintain code consistency, reduce errors, and streamline the overall development workflow, making them a valuable tool for enforcing best practices and improving code quality across a project.
+ 
+The `pre-commit` hook runs before a commit is finalized, giving a chance to inspect the staged changes and abort the commit if something is wrong. It's frequently used to run linters, formatters, or tests against the code being committed. If the hook script exits with a non-zero status, the commit is stopped.

 Visit the following resources to learn more:

- [@opensource@pre-commit/pre-commit](https://github.com/pre-commit/pre-commit)
- [@official@Git Hooks](https://www.atlassian.com/git/tutorials/git-hooks)
+- [@official@Git Hooks](https://www.atlassian.com/git/tutorials/git-hooks)
+- [@opensource@pre-commit/pre-commit](https://github.com/pre-commit/pre-commit)
@@ -1,6 +1,6 @@
 # pre-push
-
-Git pre-push hooks are scripts that run automatically before a push operation is executed, providing a final checkpoint to validate changes before they are shared with a remote repository. These hooks allow developers to perform last-minute checks, such as running tests, linting code, or verifying commit messages, to ensure that only high-quality and compliant code is pushed. By intercepting the push process, pre-push hooks help maintain code integrity, prevent accidental pushes of incomplete or broken code, and enforce project-specific rules, making them a valuable tool for maintaining code quality and consistency across distributed development teams.
+ 
+The `pre-push` hook runs before commits are pushed to a remote repository, allowing checks to run on the commits about to be shared. It's often used to run a test suite or verify that the branch is up to date before allowing the push to proceed. If the script exits with a non-zero status, the push is cancelled.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # Private vs Public
-
-GitHub offers both private and public repositories, each serving different purposes in software development. Public repositories are visible to everyone on the internet, making them ideal for open-source projects, collaboration, and showcasing work to a wider audience. They encourage community contributions and can help developers build their portfolios. Private repositories, on the other hand, are only accessible to the repository owner and designated collaborators. These are suitable for proprietary code, sensitive projects, or work that's not ready for public consumption. Private repositories offer greater control over access and visibility, making them essential for businesses and individuals who need to keep their code confidential.
+ 
+A public repository is visible to anyone on GitHub and can be cloned or viewed by other users, while a private repository restricts access to the owner and any collaborators explicitly invited. Public repositories are common for open source projects that want community contributions, while private repositories suit proprietary code or work in progress. Repository visibility can be changed later in the settings, though switching a private repo to public exposes its entire history.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # Profile Readme
-
-A GitHub Profile README is a special repository that allows users to showcase their skills, projects, and personality directly on their GitHub profile. To create one, you need to make a new repository with the same name as your GitHub username. This repository should contain a README.md file, which GitHub will automatically display on your profile page. The README can be customized with Markdown formatting, allowing you to add text, images, links, and even dynamic content like GitHub stats or recent blog posts. This feature provides a unique opportunity to make your GitHub profile more engaging and informative for visitors, effectively serving as a personalized landing page for your GitHub presence.
+ 
+A profile README is a special repository named after a GitHub username that displays custom content directly on the user's profile page. It uses standard Markdown, so developers can add text, images, badges, and links to showcase skills, projects, or contact information. GitHub automatically detects this repository and renders its README on the profile instead of requiring a separate page.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # Project Planning
-
-Project planning on GitHub is a comprehensive process that leverages the platform's built-in tools to organize, track, and manage software development projects efficiently. It typically involves using features such as Issues for task tracking, Projects for kanban-style boards, Milestones for grouping related issues and pull requests, and Labels for categorization. These tools, combined with GitHub's collaborative features like pull requests and code reviews, enable teams to create structured workflows, set priorities, assign tasks, and monitor progress throughout the development lifecycle. By centralizing project management within the same platform used for version control, GitHub streamlines communication and enhances productivity for development teams of all sizes.
+ 
+Project planning in GitHub Projects involves setting up boards, defining custom fields, and organizing tasks into a workflow that reflects how a team operates. This can include setting milestones, prioritizing issues, and assigning work to specific people or iterations. Planning ahead of time in a project board helps teams track progress and spot bottlenecks before deadlines.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
 # Project Readme
-
-A GitHub project README is a crucial document that serves as the front page of a repository, providing essential information about the project. It typically includes a brief description of the project's purpose, installation instructions, usage guidelines, and contribution procedures. A well-crafted README helps visitors quickly understand the project's goals, how to get started, and how they can participate. It often contains badges indicating build status, code coverage, and other metrics, as well as links to documentation, issue trackers, and community channels. By effectively communicating the project's value and guiding new users and potential contributors, a good README significantly enhances a project's visibility, adoption, and collaboration potential on GitHub.
+ 
+A README is the first file most people see when visiting a repository, typically explaining what the project does, how to install it, and how to use it. It's written in Markdown and rendered automatically on the repository's main page. A good README often includes usage examples, setup instructions, and links to further documentation or contribution guidelines.

 Visit the following resources to learn more:

@@ -1,13 +1,8 @@
 # Pull Requests
-
-You can use GitHub CLI to manage pull requests with the following commands:
-
- `gh pr create`: Create a new pull request.
- `gh pr merge`: Merge a pull request into the target branch.
- `gh pr list`: List all pull requests for a repository.
- `gh pr view`: View details of a specific pull request.
+ 
+GitHub CLI supports the full pull request workflow from the terminal, including creating one with `gh pr create`, reviewing changes with `gh pr diff`, and merging with `gh pr merge`. This lets developers open and manage pull requests without leaving their code editor or terminal session. It's especially useful for quickly checking pull request status during a coding session.

 Visit the following resources to learn more:

 - [@official@gh pr](https://cli.github.com/manual/gh_pr)
- [@video@Use GitHub CLI For Command Line Pull Request Management](https://www.youtube.com/watch?v=Ku9_0Mftiic)
+- [@video@Use GitHub CLI For Command Line Pull Request Management](https://www.youtube.com/watch?v=Ku9_0Mftiic)
@@ -5,5 +5,4 @@ When you pull changes in Git, you're fetching and integrating changes from a rem
 Visit the following resources to learn more:

 - [@official@Pushing commits to a remote repository](https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository)
- [@article@A Comprehensive Guide to git pull and git push](https://dev.to/alexmercedcoder/mastering-git-a-comprehensive-guide-to-git-pull-and-git-push-2eo3)
- [@article@Git Push and Pull Tutorial](https://www.datacamp.com/tutorial/git-push-pull)
+- [@article@A Comprehensive Guide to git pull and git push](https://dev.to/alexmercedcoder/mastering-git-a-comprehensive-guide-to-git-pull-and-git-push-2eo3)
@@ -4,4 +4,4 @@ Rebasing in Git is a powerful and potentially complex feature used to reorganize

 Visit the following resources to learn more:

- [@official@Rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)
+- [@official@Rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)
@@ -5,4 +5,4 @@ Renaming a branch in Git means changing the name of a branch to something differ
 Visit the following resources to learn more:

 - [@official@Renaming a Branch - GitHub Docs](https://docs.github.com/github/administering-a-repository/renaming-a-branch)
- [@article@Git Rename Branch – How to Change a Local Branch Name](https://www.freecodecamp.org/news/git-rename-branch-how-to-change-a-local-branch-name/)
+- [@article@Git Rename Branch – How to Change a Local Branch Name](https://www.freecodecamp.org/news/git-rename-branch-how-to-change-a-local-branch-name/)
@@ -1,11 +1,6 @@
 # Repository management
-
-Using GitHub CLI for repository management allows you to streamline tasks and work more efficiently. ou can use GitHub CLI to manage repositories with the following commands:
-
- `gh repo create`: Create a new repository.
- `gh repo delete`: Delete an existing repository.
- `gh repo visibility`: Change the repository's visibility (public or private).
- `gh repo topic`: Manage topic labels for a repository.
+ 
+GitHub CLI supports repository management commands like `gh repo create`, `gh repo clone`, and `gh repo view`, letting developers manage repositories without leaving the terminal. These commands mirror actions normally done through the GitHub website, such as creating a new repo or checking its details. This is especially useful for developers who prefer staying in the command line during their workflow.

 Visit the following resources to learn more:

@@ -6,4 +6,4 @@ Visit the following resources to learn more:

 - [@official@GitHub REST API documentation](https://docs.github.com/en/rest?apiVersion=2022-11-28)
 - [@official@Quickstart for GitHub REST API](https://docs.github.com/en/rest/quickstart?apiVersion=2022-11-28)
- [@video@[Tutorial] - How to use GitHub REST API for Beginners](https://www.youtube.com/watch?v=OvfLavRD1Os)
+- [@video@\[Tutorial\] - How to use GitHub REST API for Beginners](https://www.youtube.com/watch?v=OvfLavRD1Os)
@@ -1,17 +1,6 @@
 # Rewriting History
-
-In certain situations, you might need to modify or remove commits from your Git repository's history. This can be achieved using various methods:
-
- `git commit --amend`: Allows you to edit the most recent commit.
- `git rebase`: Replaces one branch with another, preserving the commit history.
- `git filter-branch`: Removes specific commits from a branch without altering the original branch.
- `git push --force`: Updates the remote repository while respecting existing pull requests.
-
-Rewriting history in Git is typically necessary when:
-
- Fixing mistakes: Correcting errors or typos in commit messages.
- Removing sensitive data: Deleting confidential information from commits, like API keys or database credentials.
- Simplifying complex histories: Reorganizing branches to improve clarity and reduce complexity.
+ 
+Rewriting history refers to Git operations that change existing commits rather than adding new ones on top, such as amending a commit message or rebasing a series of commits. These operations alter commit hashes, which can cause issues for anyone who already has a copy of the original history. Because of this, rewriting history is generally safe on local or unshared branches, but risky on branches others are actively using.

 Visit the following resources to learn more:

@@ -1,9 +1,6 @@
 # Saved Replies
-
-GitHub allows you to save frequently used comments and reuse them when discussing issues or pull requests.
-
- Saved replies: You can create pre-written comments that can be easily added to conversations.
- Customization: Saved replies can be edited to fit specific situations, making it easy to tailor your responses.
+ 
+Saved replies let users store commonly used comment templates that can be inserted into issues or pull requests with a click. This is useful for repetitive responses, like closing an issue with a standard message or thanking a contributor for their submission. GitHub provides some default saved replies, and users can add their own from the settings page.

 Visit the following resources to learn more:

@@ -1,6 +1,6 @@
-# Scheduled Worfklows
-
-GitHub Actions allows you to schedule workflows to run at specific times or intervals. You can set up workflows to automatically run at predetermined times, such as daily or weekly.
+# Scheduled Workflows
+ 
+Scheduled workflows run automatically at specified times using cron syntax under the `schedule` trigger in a workflow file. This is useful for recurring tasks like nightly builds, periodic cleanup jobs, or fetching data on a regular interval. GitHub runs scheduled workflows based on UTC time, and there can be a slight delay depending on runner availability.

 Visit the following resources to learn more:

@@ -1,9 +1,6 @@
 # Secrets and Env Vars
-
-GitHub provides features to securely store and manage sensitive data, such as secrets and environment variables.
-
- Secrets: These are sensitive values that should not be committed to a repository, like API keys or database credentials.
- Environment Variables: They can be used to set values for your workflow or application, making it easier to manage dependencies.
+ 
+Secrets store sensitive values like API keys or passwords securely, configured in a repository's settings and referenced in workflows without exposing their actual values in logs. Environment variables, defined with the `env` key, hold configuration values that steps in a workflow can access during execution. Both are commonly used together, keeping sensitive data out of the workflow file itself while still making it available where needed.

 Visit the following resources to learn more:

@@ -1,10 +1,6 @@
 # Setting up Profile
-
-On GitHub, creating a profile is an essential step in showcasing yourself as a developer or contributor.
-
- Sharing information: Your profile page allows others to find out more about you, including your interests and skills.
- Showcasing projects: You can display your notable projects and contributions, giving a glimpse into your work experience.
- Expressing identity: The profile also serves as an opportunity for personal expression, allowing you to convey your unique personality and style within the GitHub community.
+ 
+Setting up a GitHub profile involves adding a profile picture, bio, location, and links to personal or professional sites. A well-configured profile helps other developers and potential employers understand who is behind the code. GitHub also lets users pin favorite repositories to the profile page to highlight specific projects.

 Visit the following resources to learn more:

@@ -1,12 +1,9 @@
 # Staging Area
-
-In Git, a staging area serves as an intermediate step between your local repository changes and the actual commit.
-
- Temporary storage: The staging area holds changes that are intended to be part of the next commit.
- Previewing changes: It allows you to preview your changes before committing them.
+ 
+The staging area, also called the index, is where changes are prepared before being committed. Running `git add` moves specific changes from the working directory into the staging area, letting developers choose exactly what to include in the next commit. This separation gives control over grouping related changes together instead of committing every modified file at once.

 Visit the following resources to learn more:

+- [@course@Staging Area (Interactive Lesson)](https://inter-git.com/lessons/adding-files-to-index)
 - [@official@Getting Started - What is Git? - Staging Area](https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F#:~:text=The%20staging%20area%20is%20a,area%E2%80%9D%20works%20just%20as%20well.)
- [@video@What are Staged Changes in Git?](https://www.youtube.com/watch?v=HyeNfWZBut8)
- [@course@Staging Area (Interactive Lesson)](https://inter-git.com/lessons/adding-files-to-index)
+- [@video@What are Staged Changes in Git?](https://www.youtube.com/watch?v=HyeNfWZBut8)
@@ -1,9 +1,6 @@
 # Storing Artifacts
-
-GitHub provides a feature for storing artifacts, which allows you to upload build outputs or other files as part of your workflow.
-
- Artifacts: These are files generated by a job, such as compiled binaries, test reports, or logs. They can be used to validate the results of a build or deployment.
- Referenceable storage: Artifacts are stored in a referenceable way, making it easy to access and use them in future builds.
+ 
+Artifacts are files produced during a workflow run, like build outputs or test reports, that can be saved and downloaded after the workflow finishes. The `actions/upload-artifact` action stores these files, and `actions/download-artifact` retrieves them in a later job or for manual inspection. Artifacts are commonly used to pass build outputs between jobs or to keep logs and reports for review.

 Visit the following resources to learn more:

@@ -2,6 +2,6 @@

 The GitHub Student Developer Pack is a collection of developer tools and resources that are offered free or at a discounted price to students through the GitHub Education program. This pack includes access to GitHub, GitHub Desktop, GitHub Classroom, GitHub Student Developer Kit, and other benefits. By using the Student Developer Pack, students can gain hands-on experience with professional developer tools, while also getting access to a wide range of educational resources.

-Visit the following resource to learn more:
+Visit the following resources to learn more:

 - [@official@Apply to GitHub Education as a student](https://docs.github.com/en/education/explore-the-benefits-of-teaching-and-learning-with-github-education/github-education-for-students/apply-to-github-education-as-a-student)
@@ -1,9 +1,6 @@
 # Submodules
-
-In Git, submodules allow you to include another repository within a project. This feature enables the management of external dependencies as part of the main project.
-
- Including external repositories: Submodules can be used to include other Git repositories within your project.
- Managing dependencies: They provide a way to manage and track changes in external dependencies.
+ 
+A submodule is a Git repository embedded inside another repository as a subdirectory, keeping its own separate history. It allows a project to include and track a specific version of another project without merging their codebases together. Submodules are commonly used for shared libraries or dependencies that are maintained in their own repository.

 Visit the following resources to learn more:

@@ -1,9 +1,6 @@
 # Tagging
-
-In Git, tags are used to identify specific points in a repository's history as being important. This feature allows developers to mark release points or milestones.
-
- Marking release points: Tags are typically used to mark release versions (e.g., v1.0, v2.0) of a project.
- Types of tags: There are different types of tags, including lightweight and annotated tags.
+ 
+Tagging marks a specific commit as significant, typically used to denote release versions like `v1.0.0`. Unlike branches, tags don't move as new commits are added, so they act as a fixed reference point in history. Tags can be lightweight, just a name pointing to a commit, or annotated, storing extra metadata like the tagger's name and a message.

 Visit the following resources to learn more:

@@ -1,10 +1,6 @@
 # Teams within Organization
-
-GitHub Organizations allow you to create teams within your organization, which helps in organizing members based on their roles and responsibilities.
-
- Grouping: Team members can be grouped together according to the company or group's structure.
- Access permissions: Access permissions can be cascaded from one team member to another.
- Mentions: Team mentions allow for easy referencing of specific teams in repository discussions.
+ 
+Teams within a GitHub organization group members together to manage permissions more efficiently across multiple repositories. Instead of granting access to each person individually, an admin assigns access to a team, and every member inherits those permissions. This structure is useful for larger organizations where different teams, like frontend or backend developers, need different levels of access to specific repositories.

 Visit the following resources to learn more:

@@ -1,12 +1,9 @@
 # Undoing Changes
-
-If mistakes or unwanted changes have been committed to your Git repository, there are ways to correct them. Two common methods for reverting changes include:
-
- Git Reset: Resets the branch to a previous commit.
- Git Revert: Creates a new commit that reverts specified changes.
+ 
+Undoing changes in Git covers the different ways to reverse modifications, whether they're uncommitted, staged, or already committed. Depending on the situation, developers might use `git checkout` to discard local edits, `git reset` to unstage or remove commits, or `git revert` to safely undo a commit that's already been shared. Choosing the right method depends on whether the change has been pushed to a shared remote.

 Visit the following resources to learn more:

 - [@official@Undoing Changes](https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified)
 - [@article@Undo Anything in Git](https://github.blog/open-source/git/how-to-undo-almost-anything-with-git/)
- [@article@Undoing Changes in Git](https://www.atlassian.com/git/tutorials/undoing-changes)
+- [@article@Undoing Changes in Git](https://www.atlassian.com/git/tutorials/undoing-changes)
@@ -2,7 +2,7 @@

 For changes that are not yet staged with `git add`, such as untracked new files or modified existing ones , use `git diff`. This command compares your working directory (your current changes) against the staging area (changes already staged with `git add`). It’s a useful tool for reviewing local modifications before deciding whether to stage them for future commits.

-The `--unified` option (or -U) controls the number of context lines shown in the diff output. By default, Git shows 3 lines of context around each change. For example, `git diff --unified=5` will display 5 lines of context around each change, making it easier to understand the surrounding code or content.
+Visit the following resources to learn more:

 - [@article@What are unstaged changes in GitHub?](https://stackoverflow.com/questions/10954329/whats-the-unstaged-changes-in-github)
- [@article@How to unstage files in Git](https://www.git-tower.com/learn/git/faq/git-unstage)
+- [@article@How to unstage files in Git](https://www.git-tower.com/learn/git/faq/git-unstage)
@@ -1,23 +1,8 @@
 # Use in Automation
+ 
+GitHub CLI can be used inside scripts or CI/CD pipelines to automate tasks like creating releases, commenting on issues, or triggering workflows. Because it supports authentication via tokens, it can run in non-interactive environments without manual login. This makes it a common tool for building custom automation around GitHub's platform without relying on the REST API directly.

-GitHub CLI is a powerful tool for automating GitHub-related tasks directly from the command line. It enables developers to streamline workflows and integrate GitHub processes into scripts and automated systems.
-
-Key uses in automation:
-
-1. CI/CD: Automate PR creation, review, merging, and release management
-2. Issue and Project Management: Create, update, and close issues; manage project boards
-3. Repository Management: Clone repos, create forks, manage settings and collaborators
-4. GitHub Actions Integration: Trigger and monitor workflows, manage secrets
-5. Scripting and Batch Operations: Perform bulk actions across multiple repositories
-
-To use GitHub CLI in automation:
-
-1. Install GitHub CLI
-2. Authenticate with your GitHub account
-3. Learn basic commands and syntax
-4. Integrate CLI commands into scripts or automation tools
-
-Learn more from the following resources:
+Visit the following resources to learn more:

 - [@official@GitHub CLI documentation](https://cli.github.com/manual/)
 - [@article@Automating your workflow with GitHub CLI](https://github.blog/2021-03-11-scripting-with-github-cli/)
@@ -1,19 +1,8 @@
 # Usecases
+ 
+Common use cases for GitHub Actions include running automated tests on every pull request, building and deploying applications, publishing packages, and sending notifications. It can also automate repository maintenance tasks, like labeling issues or closing stale pull requests. Because workflows can be triggered by nearly any GitHub event, teams use Actions to automate a wide range of development and operations tasks.

-GitHub Actions offer a wide range of automation possibilities for your development workflow. Here are some common use cases:
-
-1. Continuous Integration (CI): Automatically build and test your code on every push or pull request.
-2. Continuous Deployment (CD): Automatically deploy your application to various environments after successful builds.
-3. Code Quality Checks: Run linters, formatters, and other code quality tools automatically.
-4. Dependency Updates: Automatically create pull requests for outdated dependencies.
-5. Issue and PR Management: Automatically label, assign, or close issues and pull requests based on certain conditions.
-6. Scheduled Tasks: Run periodic maintenance tasks, backups, or data processing jobs.
-7. Security Scanning: Perform automated security checks on your codebase and dependencies.
-8. Documentation Generation: Automatically generate and publish documentation for your project.
-9. Cross-platform Testing: Test your code on multiple operating systems and environments simultaneously.
-10. Release Management: Automate the creation of release notes and asset uploads for new versions.
-
-Learn more from the following resources:
+Visit the following resources to learn more:

 - [@official@GitHub Actions Documentation](https://docs.github.com/en/actions)
- [@youtube@How GitHub Actions 10x my productivity](https://www.youtube.com/watch?v=yfBtjLxn_6k)
+- [@article@How GitHub Actions 10x my productivity](https://www.youtube.com/watch?v=yfBtjLxn_6k)
@@ -1,6 +1,6 @@
 # Viewing Commit History
-
-Viewing commit history is a crucial aspect of Git, allowing users to examine the chronological record of repository changes. This feature is essential for understanding project evolution, tracking modifications, and facilitating effective team collaboration. Git provides various commands like `git log` and its options (e.g., `--oneline`, `--graph`, `--patch`, `--stat`) to display commit history in different formats. Users can filter commits by author, date range, and other criteria. By regularly reviewing commit history and following best practices such as writing clear commit messages and using tags, developers can gain valuable insights into their project's development and make informed decisions about future changes.
+ 
+Viewing commit history shows the sequence of commits made to a repository, typically through the `git log` command. Each entry includes the commit hash, author, date, and message, giving a record of how the project evolved. Developers use this history to understand past changes, find when a bug was introduced, or review someone else's work.

 Visit the following resources to learn more:

@@ -5,4 +5,4 @@ Viewing diffs in Git is crucial for understanding the changes made to your code.
 Visit the following resources to learn more:

 - [@official@Git Diff Documentation](https://git-scm.com/docs/git-diff)
- [@article@Git Diff](https://www.atlassian.com/git/tutorials/saving-changes/git-diff)
+- [@article@Git Diff](https://www.atlassian.com/git/tutorials/saving-changes/git-diff)
@@ -1,25 +1,8 @@
 # What and Why use?
+ 
+Submodules let a project reference another Git repository at a specific commit, rather than copying its code directly into the main project. This is useful when multiple projects depend on the same shared library and need to track updates to it independently. Using a submodule keeps the dependency's history separate while still linking it to a fixed point in the parent project.

-Git submodules are a feature that allows you to include one Git repository within another. They are useful for managing external dependencies or shared components across projects.
-
-## Key points
-
-1. Separate repositories with independent histories
-2. Parent repository tracks specific submodule commits
-3. Enables code reuse and modular project structure
-4. Helps manage dependencies and keep main repository focused
-5. Facilitates collaboration on complex projects
-
-## Benefits
-
- Including third-party libraries
- Sharing common code
- Managing multi-component projects
- Keeping main repository lightweight
-
-Note: While powerful, submodules can add complexity to your workflow, so careful consideration is needed before implementation.
-
-Learn more from the following resources:
+Visit the following resources to learn more:

 - [@article@Git Submodules: Core Concept, Workflows, and Tips](https://www.atlassian.com/git/tutorials/git-submodule)
- [@video@Git Submodules Tutorial](https://www.youtube.com/watch?v=gSlXo2iLBro)
+- [@video@Git Submodules Tutorial](https://www.youtube.com/watch?v=gSlXo2iLBro)
@@ -1,8 +1,8 @@
 # What and Why?
+ 
+Git hooks let developers automate tasks or enforce rules at key points in the Git workflow, such as validating a commit message or running a linter before code gets committed. They exist because manually remembering to run checks before every commit or push is error-prone and easy to skip. By automating these checks, hooks help maintain consistency and catch problems earlier in the development process.

-Git hooks are customizable scripts that Git executes automatically before or after specific events, such as committing, pushing, or merging. These hooks allow developers to automate tasks, enforce coding standards, run tests, or perform other actions at crucial points in the Git workflow. By leveraging git hooks, teams can enhance their development process, maintain code quality, and ensure consistency across projects. Hooks can be implemented locally or shared among team members, providing a powerful mechanism for streamlining workflows and enforcing best practices throughout the development lifecycle.
-
-Learn more from the following resources:
+Visit the following resources to learn more:

 - [@article@Git Hooks](https://www.atlassian.com/git/tutorials/git-hooks)
 - [@video@What are Git Hooks?](https://www.youtube.com/watch?v=1OFiiPretCM)
--- a/Show More
+++ b/Show More