Add content to git/github roadmap (up to git-worktree) (#6587)

* Add content to git/github roadmap (up to git-worktree)

* Apply suggestions from code review

add links to topics with no links.

---------

Co-authored-by: dsh <daniel.s.holdsworth@gmail.com>
pull/6602/head
Stavros Siamantas 3 months ago committed by GitHub
parent 9d8c7f7253
commit 0d5355018b
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
  1. 6
      src/data/roadmaps/git-github/content/--hard@V_joZNpQsS9G9PI-o-GmC.md
  2. 4
      src/data/roadmaps/git-github/content/--mixed@qis7Z5VRxMcOmbesQlegZ.md
  3. 4
      src/data/roadmaps/git-github/content/--soft@Uc7FyfAKpDFRGRNHwztFo.md
  4. 7
      src/data/roadmaps/git-github/content/adding--updating@x4bnsPVTiX2xOCSyrgWpF.md
  5. 7
      src/data/roadmaps/git-github/content/automations@TNBz5755PhI6iKxTQTqcS.md
  6. 5
      src/data/roadmaps/git-github/content/between-branches@O-zoAWkDvyn7B8_TmY257.md
  7. 5
      src/data/roadmaps/git-github/content/between-commits@Rwpeltygwzcf6hnuZNURE.md
  8. 7
      src/data/roadmaps/git-github/content/branch-naming@ks1Pip-RM-UWD6zuF2j4n.md
  9. 7
      src/data/roadmaps/git-github/content/branching-basics@bXfCUG3h1TIFPgD4WUDph.md
  10. 12
      src/data/roadmaps/git-github/content/caching-dependencies@HMNhzzV6ApTKj4I_FOmUB.md
  11. 2
      src/data/roadmaps/git-github/content/checkout-branch@PtRo-wGiNAagZ6CykfvMr.md
  12. 2
      src/data/roadmaps/git-github/content/checkout-tags@62E1tDMXB6K74OEN0WsS0.md
  13. 2
      src/data/roadmaps/git-github/content/cherry-picking-commits@eFf2fesrs-1aVM5tH3ORQ.md
  14. 2
      src/data/roadmaps/git-github/content/clean-git-history@i3AbARgzQtxtlB-1AS8zv.md
  15. 2
      src/data/roadmaps/git-github/content/client-vs-server-hooks@zsU6R2zvJKnYNU2ac4o4p.md
  16. 2
      src/data/roadmaps/git-github/content/cloning-repositories@1Koej79yTv-OAswVZwgGq.md
  17. 3
      src/data/roadmaps/git-github/content/code-reviews@xLB2fhsOm0Vu3xg_PusJB.md
  18. 2
      src/data/roadmaps/git-github/content/collaboration-on-github@d_GNnB6PBINz1jxGNWAE-.md
  19. 2
      src/data/roadmaps/git-github/content/collaboration@bXfCUG3h1TIFPgD4WUDph.md
  20. 5
      src/data/roadmaps/git-github/content/collaborators--members@_ft-uvXt6s_xrcMT3fbSF.md
  21. 3
      src/data/roadmaps/git-github/content/collaborators@r-u1vTpUyuvsB0revOU0C.md
  22. 2
      src/data/roadmaps/git-github/content/commit-messages@7lRUYWNSpHvJ-QyIE8RMa.md
  23. 7
      src/data/roadmaps/git-github/content/commit-msg@jzYjHx-gIKSP8dQUTqWVw.md
  24. 4
      src/data/roadmaps/git-github/content/committing-changes@2_z3R7seCvQVj-Na4H1SV.md
  25. 2
      src/data/roadmaps/git-github/content/contribution-guidelines@pJ-najh7dXhhYA_0bDiR5.md
  26. 5
      src/data/roadmaps/git-github/content/creating-account@i7fIIHcBEk473te8bniJ5.md
  27. 2
      src/data/roadmaps/git-github/content/creating-branch@OegitQ5Ngjvd3ZfMpfrkM.md
  28. 2
      src/data/roadmaps/git-github/content/creating-repositories@c_FO6xMixrrMo6iisfsvl.md
  29. 2
      src/data/roadmaps/git-github/content/deleting-branch@1uDenoQ6zu7CT69FR2iQB.md
  30. 7
      src/data/roadmaps/git-github/content/detached-head@0cLf7FiI9CX--UX45sm2f.md
  31. 15
      src/data/roadmaps/git-github/content/documentation@D2WIExwfSnkAPIa5O-Hp5.md
  32. 2
      src/data/roadmaps/git-github/content/fast-forward-vs-non-ff@agtPWS8j6i6wQPk10cy8E.md
  33. 8
      src/data/roadmaps/git-github/content/fetch-without-merge@Gybnekbd1rJKTOf4hJ4Sh.md
  34. 2
      src/data/roadmaps/git-github/content/forking-vs-cloning@l1Wf7Pe_ah8ycCgslfSK4.md
  35. 8
      src/data/roadmaps/git-github/content/git-attributes@CGj_UX5JMOOCKinedsNRc.md
  36. 8
      src/data/roadmaps/git-github/content/git-bisect@ExXuwTQSI_lg4SRGW3Iu1.md
  37. 8
      src/data/roadmaps/git-github/content/git-commit---amend@NjPnEXLf1Lt9qzgxccogv.md
  38. 2
      src/data/roadmaps/git-github/content/git-config@NMCWgzhhfUvFOMO5GbF_u.md
  39. 13
      src/data/roadmaps/git-github/content/git-hooks@pqBV7BMAs0z6qpfZeW2XP.md
  40. 2
      src/data/roadmaps/git-github/content/git-init@1iOkbO5juk2LO-WZHx_W6.md
  41. 7
      src/data/roadmaps/git-github/content/git-lfs@zdunaucVe8J1tKf_z-NQo.md
  42. 20
      src/data/roadmaps/git-github/content/git-log-options@qFEonbCMLri8iA0yONwuf.md
  43. 7
      src/data/roadmaps/git-github/content/git-patch@sFf1PdFfmEdQxsEntfeFq.md
  44. 7
      src/data/roadmaps/git-github/content/git-push---force@OQOmxg9mCfcjt80hpvXkA.md
  45. 2
      src/data/roadmaps/git-github/content/git-rebase@HMEfUFNu_Wp_Pac7VWHr-.md
  46. 2
      src/data/roadmaps/git-github/content/git-reflog@hru0sL1-D4bJSQI1efEyU.md
  47. 7
      src/data/roadmaps/git-github/content/git-remotes@aWx9WHUrgofcTr8B-fQYe.md
  48. 7
      src/data/roadmaps/git-github/content/git-reset@igrR7LguU1jemg_mf_AD6.md
  49. 13
      src/data/roadmaps/git-github/content/git-revert@dLr55Om7IOvI53c1DgTKc.md
  50. 13
      src/data/roadmaps/git-github/content/git-stash-basics@X9K3PBpGsMoXkJsKdJPI7.md
  51. 11
      src/data/roadmaps/git-github/content/git-vs-other-vcs@_jSTrYN9G8EsGHkbusKPU.md
  52. 7
      src/data/roadmaps/git-github/content/git-worktree@4dxVN81rXWn6VZqK99yq0.md
  53. 2
      src/data/roadmaps/git-github/content/staged-changes@mzjtCdpke1ayHcEuS-YUS.md
  54. 5
      src/data/roadmaps/git-github/content/unstaged-changes@uxqJzQFRcALqatNRIWR0w.md

@ -1 +1,7 @@
# --hard # --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.
Visit the following resources to learn more:
- [@official@--hard documentation](https://git-scm.com/docs/git-reset#Documentation/git-reset.txt---hard)

@ -1 +1,5 @@
# --mixed # --mixed
When using mixed mode, the HEAD pointer is moved to the specified commit. However, files in your working directory remain as they were before the reset. The staging area (index) is updated to match the specified commit.
- [@official@--mixed documentation](https://git-scm.com/docs/git-reset#Documentation/git-reset.txt---hard)

@ -1 +1,5 @@
# --soft # --soft
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.
- [@official@--soft documentation](https://git-scm.com/docs/git-reset#Documentation/git-reset.txt---hard)

@ -1 +1,8 @@
# Adding / Updating # Adding / Updating
To add a submodule to a repository, use `git submodule add https://github.com/user/submodule-repo.git`, which is the typical format for specifying the URL of the submodule repository. This creates a new folder for the submodule and checks it out at the specified revision. To update an existing submodule to its latest commit, run `git submodule update`. If you want to pull in changes from upstream while keeping your submodule's history intact, use `git submodule sync` followed by `git submodule update`.
Visit the following resources to learn more:
- [@article@Git submodules](https://www.atlassian.com/git/tutorials/git-submodule)
- [@article@Working with submodules](https://github.blog/open-source/git/working-with-submodules/)

@ -1 +1,8 @@
# Automations # Automations
To add automation to your GitHub project, use built-in workflows that can trigger actions such as setting fields on item changes or archiving items meeting specific criteria, and also configure automatic item addition from repositories based on matching criteria.
Visit the following resources to learn more:
- [@official@Automating your project](https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project)
- [@video@GitHub Project Management - Create GitHub Project Board & Automations](https://www.youtube.com/watch?v=oPQgFxHcjAw&t=600s)

@ -1 +1,6 @@
# Between Branches # Between Branches
When comparing the differences between two branches, such as a feature branch and its upstream parent branch, use `git diff <branch1>..<branch2>`. This command displays the changes made on the feature branch relative to the parent branch. It's useful for reviewing the impact of new features or changes before merging them into your mainline.
- [@article@How to compare branches in Git diff](https://scribehow.com/shared/How_to_Compare_Branches_in_GitHub__xsotezV-S1O-GL0PquqJwQ)
- [@article@How can I see the differences between two branches?](https://stackoverflow.com/questions/9834689/how-can-i-see-the-differences-between-two-branches)

@ -1 +1,6 @@
# Between Commits # Between Commits
To compare two specific commits in your Git history, use git diff followed by the hashes of the commits. This will show you the changes made between those two points, including added, modified, and deleted lines.
- [@article@Comparing changes with Git diff](https://refine.dev/blog/git-diff-command/)
- [@video@Git Diff 2 Different Commits, Tags or Branches](https://www.youtube.com/watch?v=uq5VWPDCtFo)

@ -1 +1,8 @@
# Branch Naming # 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.
Visit the following resources to learn more:
- [@article@Naming conventions for Git Branches — a Cheatsheet](https://medium.com/@abhay.pixolo/naming-conventions-for-git-branches-a-cheatsheet-8549feca2534)
- [@article@Git Branching Naming Convention: Best Practices to Follow](https://phoenixnap.com/kb/git-branch-name-convention)

@ -1 +1,8 @@
# Branching Basics # Branching Basics
Branches in Git serve as separate lines of development that allow multiple features or changes to be worked on simultaneously without affecting the main codebase. With branches, you can create isolated environments for different tasks, collaborate with others, and manage complex workflows.
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)
- [@video@Git Branches Tutorial](https://www.youtube.com/watch?v=e2IbNHi4uCI)

@ -1 +1,13 @@
# Caching Dependencies # 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.
Visit the following resources to learn more:
- [@official@Caching dependencies to speed up workflows](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows)
- [@video@Cache Management with GitHub actions](https://www.youtube.com/watch?v=7PVUjRXUY0o)

@ -2,7 +2,7 @@
In Git, to "checkout" from a branch means to switch your working directory to that branch, making it the active branch. This updates your files to match the state of that branch and allows you to work on it. In Git, to "checkout" from a branch means to switch your working directory to that branch, making it the active branch. This updates your files to match the state of that branch and allows you to work on it.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@git-checkout](https://git-scm.com/docs/git-checkout) - [@official@git-checkout](https://git-scm.com/docs/git-checkout)
- [@article@git-commands-checkout](https://www.git-tower.com/learn/git/commands/git-checkout) - [@article@git-commands-checkout](https://www.git-tower.com/learn/git/commands/git-checkout)

@ -2,7 +2,7 @@
Tags in Git are typically used to mark specific points in history, such as a release version. Checking out a tag means switching your working directory to the state of the repository at the point in time when that tag was created. Tags in Git are typically used to mark specific points in history, such as a release version. Checking out a tag means switching your working directory to the state of the repository at the point in time when that tag was created.
Learn more from the following resources: Visit the following resources to learn more:
- [@article@How To Checkout Git Tags](https://devconnected.com/how-to-checkout-git-tags/) - [@article@How To Checkout Git Tags](https://devconnected.com/how-to-checkout-git-tags/)
- [@article@What is git tag, How to create tags & How to checkout git remote tag(s)](https://stackoverflow.com/questions/35979642/what-is-git-tag-how-to-create-tags-how-to-checkout-git-remote-tags) - [@article@What is git tag, How to create tags & How to checkout git remote tag(s)](https://stackoverflow.com/questions/35979642/what-is-git-tag-how-to-create-tags-how-to-checkout-git-remote-tags)

@ -2,7 +2,7 @@
Cherry-picking in Git allows you to apply a specific commit from one branch to another, without merging the entire branch. This is useful when you want to bring in a specific feature or fix from one branch to another without incorporating all the changes from the source branch. Cherry-picking in Git allows you to apply a specific commit from one branch to another, without merging the entire branch. This is useful when you want to bring in a specific feature or fix from one branch to another without incorporating all the changes from the source branch.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@git-cherry-pick-docs](https://git-scm.com/docs/git-cherry-pick) - [@official@git-cherry-pick-docs](https://git-scm.com/docs/git-cherry-pick)
- [@article@Git cherry pick](https://www.atlassian.com/git/tutorials/cherry-pick) - [@article@Git cherry pick](https://www.atlassian.com/git/tutorials/cherry-pick)

@ -7,7 +7,7 @@ Cleaning up Git history can make your commit history more readable, concise, and
- To be able to deploy any commit on your development branch using your CI/CD system - 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. - If you are handling mobile app releases and you are responsible for figuring out what feature is in which release.
Learn more from the following resources: Visit the following resources to learn more:
- [@article@Clean GIT history — a Step by Step Guide](https://medium.com/@catalinaturlea/clean-git-history-a-step-by-step-guide-eefc0ad8696d) - [@article@Clean GIT history — a Step by Step Guide](https://medium.com/@catalinaturlea/clean-git-history-a-step-by-step-guide-eefc0ad8696d)
- [@video@Git best practice tip: clean commit history](https://youtu.be/bZpiVijzd2g?si=8lJTlR3LfY9ZUd77) - [@video@Git best practice tip: clean commit history](https://youtu.be/bZpiVijzd2g?si=8lJTlR3LfY9ZUd77)

@ -2,7 +2,7 @@
Like many other Version Control Systems, Git has a way to fire off custom scripts when certain important actions occur. There are two groups of these hooks: client-side and server-side. Client-side hooks are triggered by operations such as committing and merging, while server-side hooks run on network operations such as receiving pushed commits. Like many other Version Control Systems, Git has a way to fire off custom scripts when certain important actions occur. There are two groups of these hooks: client-side and server-side. Client-side hooks are triggered by operations such as committing and merging, while server-side hooks run on network operations such as receiving pushed commits.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@Git Hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks#:~:text=There%20are%20two%20groups%20of,for%20all%20sorts%20of%20reasons.) - [@official@Git Hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks#:~:text=There%20are%20two%20groups%20of,for%20all%20sorts%20of%20reasons.)
- [@article@Git Hooks: The Powerful Tool You're Probably Not Using](https://dev.to/algodame/git-hooks-the-powerful-tool-youre-probably-not-using-but-should-be-1lec) - [@article@Git Hooks: The Powerful Tool You're Probably Not Using](https://dev.to/algodame/git-hooks-the-powerful-tool-youre-probably-not-using-but-should-be-1lec)

@ -1,7 +1,7 @@
# Cloning Repositories # Cloning Repositories
Cloning a repository in Git and GitHub involves creating a local copy of a remote repository on your computer. This allows you to work on the project locally, commit changes, and later push those changes back to the remote repository. Cloning a repository in Git and GitHub involves creating a local copy of a remote repository on your computer. This allows you to work on the project locally, commit changes, and later push those changes back to the remote repository.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@Git clone](https://git-scm.com/docs/git-clone/en) - [@official@Git clone](https://git-scm.com/docs/git-clone/en)
- [@official@Cloning a repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository) - [@official@Cloning a repository](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository)

@ -1,6 +1,5 @@
# Code Reviews # 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. 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: Some of the benefits of code reviews include:
@ -10,7 +9,7 @@ Some of the benefits of code reviews include:
- 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. - 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. - Ensure that the code is maintainable by identifying any software maintenance issues and suggesting improvements.
Learn more from the following links: 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@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)

@ -2,7 +2,7 @@
Collaboration on GitHub is a powerful way for multiple people to work together on the same project, using Git as the version control system. GitHub provides various tools and workflows that make collaboration efficient and organized. Collaboration on GitHub is a powerful way for multiple people to work together on the same project, using Git as the version control system. GitHub provides various tools and workflows that make collaboration efficient and organized.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@How to collaborate in a GitHub project](https://gist.github.com/neklaf/9002d3acccf6b6e448db5c4c4e8764c0) - [@official@How to collaborate in a GitHub project](https://gist.github.com/neklaf/9002d3acccf6b6e448db5c4c4e8764c0)
- [@article@Best Practices for collaborating in github](https://www.gitkraken.com/blog/collaborate-on-github) - [@article@Best Practices for collaborating in github](https://www.gitkraken.com/blog/collaborate-on-github)

@ -2,7 +2,7 @@
When working on projects with others, Git provides tools to facilitate collaboration through forking repositories using `git clone` or `git fork`, cloning them locally with git clone, managing pull requests with `git request-pull`, and resolving merge conflicts. To contribute effectively, follow established contributing guides and respect open-source licences that govern how contributors' work may be used by others. When working on projects with others, Git provides tools to facilitate collaboration through forking repositories using `git clone` or `git fork`, cloning them locally with git clone, managing pull requests with `git request-pull`, and resolving merge conflicts. To contribute effectively, follow established contributing guides and respect open-source licences that govern how contributors' work may be used by others.
Learn more from the following resources: Visit the following resources to learn more:
- [@article@Git Fork and Git Clone: The difference and why it's important!](https://dev.to/danielasaboro/git-fork-and-clone-whats-the-difference-190c) - [@article@Git Fork and Git Clone: The difference and why it's important!](https://dev.to/danielasaboro/git-fork-and-clone-whats-the-difference-190c)
- [@article@About pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) - [@article@About pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)

@ -1 +1,6 @@
# Collaborators / Members # Collaborators / Members
In GitHub, collaborators and members refer to individuals who contribute to or have access to your repository. Collaborators are users who have been granted permission to contribute code, make changes, and push updates to your repository, whereas members are the owners of a repository, including organization owners who have full control over their team's repositories. Members can be either individual collaborators or part of an organization team, with varying levels of access and permissions based on their role within the team.
- [@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)

@ -2,11 +2,10 @@
Collaborators in GitHub are users who have been granted direct access to a repository by the repository owner or organization administrators. Collaborators can perform actions like pushing commits, creating branches, and managing issues or pull requests, depending on the permissions granted to them. They are typically added to private repositories or to public repositories where more control over contributions is needed. Collaborators in GitHub are users who have been granted direct access to a repository by the repository owner or organization administrators. Collaborators can perform actions like pushing commits, creating branches, and managing issues or pull requests, depending on the permissions granted to them. They are typically added to private repositories or to public repositories where more control over contributions is needed.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@How to add collaborators to your personal projects](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@How to add collaborators to your personal projects](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@Adding outside collaborators to repositories in your organization](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-outside-collaborators/adding-outside-collaborators-to-repositories-in-your-organization) - [@official@Adding outside collaborators to repositories in your organization](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-outside-collaborators/adding-outside-collaborators-to-repositories-in-your-organization)
- [@article@What are github collaborators](https://www.geeksforgeeks.org/what-are-github-collaborators/) - [@article@What are github collaborators](https://www.geeksforgeeks.org/what-are-github-collaborators/)
- [@article@How to Add Collaborators to Your GitHub Repository](https://www.blinkops.com/blog/how-to-add-collaborators-to-your-github-repository) - [@article@How to Add Collaborators to Your GitHub Repository](https://www.blinkops.com/blog/how-to-add-collaborators-to-your-github-repository)
- [@video@Using Github for Team collaboration](https://youtu.be/4nyIS58ORWw?si=yK5LCONNVm9OIUK5) - [@video@Using Github for Team collaboration](https://youtu.be/4nyIS58ORWw?si=yK5LCONNVm9OIUK5)

@ -2,7 +2,7 @@
A Git commit message is a brief explanation of the changes introduced in a particular commit. It helps others (and your future self) understand the purpose of the changes and the context behind them. Writing clear and informative commit messages is an important practice for maintaining a well-organized and easily navigable project history. A Git commit message is a brief explanation of the changes introduced in a particular commit. It helps others (and your future self) understand the purpose of the changes and the context behind them. Writing clear and informative commit messages is an important practice for maintaining a well-organized and easily navigable project history.
Learn more from the following resources: 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@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@Writing good commit messages](https://www.theodinproject.com/lessons/foundations-commit-messages)

@ -1 +1,8 @@
# commit-msg # commit-msg
The commit-msg hook is a client-side hook that runs after you've committed changes to your repository. It's typically used to validate or modify the commit message before it's recorded in the Git history.
Visit the following resources to learn more:
- [@article@A Git-Hook for Commit Messages Validation - No Husky, Just JS](https://dev.to/mbarzeev/a-git-hook-for-commit-messages-validation-no-husky-just-js-1hni)
- [@video@Git Hooks Made Easy: Create a Custom 'commit-msg' Hook Script](https://www.youtube.com/watch?v=yH1lBm5t97s)

@ -1,8 +1,8 @@
# Committing Changes # 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 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.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@How git commit works](https://github.com/git-guides/git-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) - [@article@Git commit](https://www.atlassian.com/git/tutorials/saving-changes/git-commit)

@ -2,7 +2,7 @@
Contribution guidelines are essential for collaborative projects on GitHub as they help streamline collaboration, set expectations for contributions, and maintain the project's quality and consistency. Contribution guidelines are essential for collaborative projects on GitHub as they help streamline collaboration, set expectations for contributions, and maintain the project's quality and consistency.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@Setting guidelines for respository contributors](https://docs.github.com/articles/setting-guidelines-for-repository-contributors) - [@official@Setting guidelines for respository contributors](https://docs.github.com/articles/setting-guidelines-for-repository-contributors)
- [@official@Contributing Guidelines](https://github.blog/news-insights/contributing-guidelines/) - [@official@Contributing Guidelines](https://github.blog/news-insights/contributing-guidelines/)

@ -1,8 +1,7 @@
# Creating Account # Creating Account
To get started with GitHub, you'll need to create a free personal account on GitHub.com and verify your email address. 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.
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.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@Creating an account on GitHub](https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github) - [@official@Creating an account on GitHub](https://docs.github.com/en/get-started/start-your-journey/creating-an-account-on-github)

@ -2,7 +2,7 @@
Creating a branch in Git is a fundamental part of working with version control, allowing you to work on different features or fixes without affecting the main codebase. You can create branches either through the terminal or github interface Creating a branch in Git is a fundamental part of working with version control, allowing you to work on different features or fixes without affecting the main codebase. You can create branches either through the terminal or github interface
Learn more from the following resources: Visit the following resources to learn more:
- [@official@Git branch documentation](https://git-scm.com/docs/git-branch) - [@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)

@ -2,6 +2,6 @@
Creating a Git repository means setting up a system to track changes in your project's files over time. This is crucial for version control, allowing you to manage, review, and collaborate on code efficiently. Creating a Git repository means setting up a system to track changes in your project's files over time. This is crucial for version control, allowing you to manage, review, and collaborate on code efficiently.
Learn more from the following resources: 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)

@ -2,7 +2,7 @@
Deleting a Git branch means removing a line of development from your Git repository. A branch in Git is essentially a pointer to a specific commit, representing an independent line of development. When you delete a branch, you’re removing this pointer, making that line of development no longer accessible through the branch name. Deleting a Git branch means removing a line of development from your Git repository. A branch in Git is essentially a pointer to a specific commit, representing an independent line of development. When you delete a branch, you’re removing this pointer, making that line of development no longer accessible through the branch name.
Learn more from the following resources: 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) - [@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/)

@ -1 +1,8 @@
# Detached HEAD # 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.
Visit the following resources to learn more:
- [@article@How to resolve detached HEAD state in Git](https://graphite.dev/guides/how-to-resolve-detached-head-state-in-git)
- [@video@Head & Detached Head](https://www.youtube.com/watch?v=HvDjbAa9ZsY)

@ -1 +1,16 @@
# Documentation # 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.
Visit the following resources to learn more:
- [@article@How to Manage Documentation in a GitHub Repository: A Guide for Junior Developers](https://dev.to/mochafreddo/how-to-manage-documentation-in-a-github-repository-a-guide-for-junior-developers-pgo)

@ -7,7 +7,7 @@ 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 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.
Learn more from the following resources: 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 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@Git Merge: To Squash Or Fast-Forward?](https://dev.to/trpricesoftware/git-merge-to-squash-or-fast-forward-3791)

@ -1 +1,9 @@
# Fetch without Merge # 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.
Visit the following resources to learn more:
- [@official@Git Fetch](https://git-scm.com/docs/git-fetch)
- [@article@Git fetch](https://www.atlassian.com/git/tutorials/syncing/git-fetch)
- [@video@Git Fetch | What is Git Fetch and How to Use it | Learn Git](https://www.youtube.com/watch?v=uEEcw1s_wWk)

@ -4,7 +4,7 @@ Forking and cloning are two fundamental concepts in Git, particularly when worki
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. 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 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.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@The difference between forking and cloning a repository](https://github.com/orgs/community/discussions/35849) - [@official@The difference between forking and cloning a repository](https://github.com/orgs/community/discussions/35849)
- [@article@Git fork vs. clone: What's the difference?](https://www.theserverside.com/answer/Git-fork-vs-clone-Whats-the-difference) - [@article@Git fork vs. clone: What's the difference?](https://www.theserverside.com/answer/Git-fork-vs-clone-Whats-the-difference)

@ -1 +1,9 @@
# Git Attributes # 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.
Visit the following resources to learn more:
- [@official@Customizing Git - Git Attributes](https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes)
- [@opensource@gitattributes/gitattributes](https://github.com/gitattributes/gitattributes)
- [@article@The benefits of git attributes and how to set them up](https://medium.com/@cloudwala/the-benefits-of-git-attributes-and-how-to-set-them-up-87f90251b8e0)

@ -1 +1,9 @@
# Git Bisect # Git Bisect
Git Bisect is an interactive tool used to identify which commit in your project's history introduced a bug or regression. You start by identifying two commits: one where the issue isn't present (the "good" commit) and another where it is (the "bad" commit). Then, run `git bisect start`, followed by `git bisect good` for the good commit and `git bisect bad` for the bad commit. Git Bisect will guide you through a binary search process, asking you to test the midpoint of your current range until it identifies the exact commit that introduced the bug or regression.
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)
- [@video@Git Bisect | How to use Git Bisect | Learn Git](https://www.youtube.com/watch?v=z-AkSXDqodc)

@ -1 +1,9 @@
# git commit --amend # git commit --amend
`git commit --amend` is a command used to modify the most recent commit in your repository's history by updating its message, adding or removing files, or changing the commit's metadata. This allows you to correct mistakes or improve the commit's description after it has been made. When using --amend, Git will replace the existing commit with a new one that includes any changes made since the last commit, effectively "amending" the previous commit.
Visit the following resources to learn more:
- [@article@Changing a commit message](https://docs.github.com/en/enterprise-cloud@latest/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message)
- [@article@Rewriting history](https://www.atlassian.com/git/tutorials/rewriting-history)
- [@video@Git Amend Tutorial: Rewrite Git History](https://www.youtube.com/watch?v=q53umU5vMkk)

@ -4,7 +4,7 @@ The `git config` command is a convenience function that is used to set Git confi
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` 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`
Learn more from the following resources: Visit the following resources to learn more:
- [@official@Git - git-config Documentation](https://git-scm.com/docs/git-config) - [@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@git config | Atlassian Git Tutorial](https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-config)

@ -1 +1,14 @@
# Git hooks # 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.
Visit the following resources to learn more:
- [@official@Customizing Git - Git Hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
- [@article@Git hooks](https://www.atlassian.com/git/tutorials/git-hooks)
- [@video@What are GitHooks? Explained in 5 minutes](https://www.youtube.com/watch?v=1OFiiPretCM)

@ -2,7 +2,7 @@
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. 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.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@Git - git-init Documentation](https://git-scm.com/docs/git-init) - [@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.) - [@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 +1,8 @@
# Git LFS # Git LFS
Git Large File Storage (LFS) is an extension that helps manage large files by tracking metadata, not storing entire files. It allows storing and tracking binary assets like images, videos, audio files separately from your regular Git repository. By storing only metadata in your Git repository, you improve clone and push times, reducing storage usage. This approach is particularly useful for media repositories, large dataset storage, and binary asset management in game development. Note that Git LFS requires a separate server or storage system to store actual file content.
Visit the following resources to learn more:
- [@article@Learning About Git Large File System (LFS)](https://medium.com/swlh/learning-about-git-large-file-system-lfs-72e0c86cfbaf)
- [@video@Git LFS (Large File Storage) | Learn Git](https://www.youtube.com/watch?v=jXsvFfksvd0)

@ -1 +1,21 @@
# git log options # 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.
- --all: Show all branches in the repository.
- --graph: Display the commit history as a graph.
- --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.
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)

@ -1 +1,8 @@
# Git Patch # Git Patch
In Git, a patch is a file that contains a set of changes made to a project's codebase. It's essentially a diff (difference) file that shows the modifications between two versions of a commit or a branch. However, despite its usefulness in certain contexts, the use of Git patches has declined somewhat with the advent of more modern and efficient ways to manage code changes.
Visit the following resources to learn more:
- [@article@Git Patch](https://www.gitkraken.com/learn/git/git-patch)
- [@article@How to generate and apply patches with git?](https://gist.github.com/nepsilon/22bc62a23f785716705c)

@ -1 +1,8 @@
# git push --force # 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.
Visit the following resources to learn more:
- [@article@Git Push Force](https://www.gitkraken.com/learn/git/problems/git-push-force)
- [@video@How to force push to GitHub?](https://www.youtube.com/watch?v=wgXbfLn-zkI)

@ -2,7 +2,7 @@
Git rebase is a powerful command in Git that allows you to integrate changes from one branch into another. Unlike git merge, which creates a new commit to combine the histories of two branches, git rebase moves or applies commits from one branch on top of another, effectively re-writing the commit history. Git rebase is a powerful command in Git that allows you to integrate changes from one branch into another. Unlike git merge, which creates a new commit to combine the histories of two branches, git rebase moves or applies commits from one branch on top of another, effectively re-writing the commit history.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@Git - git-rebase Documentation](https://git-scm.com/docs/git-rebase) - [@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) - [@article@git rebase ](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase)

@ -2,7 +2,7 @@
Git reflog is a powerful tool in Git that keeps a record of all the changes made to the branches and commits in your repository, including actions that are not part of the regular commit history, such as resetting branches or checking out commits. It's particularly useful for recovering lost commits or understanding the history of changes in your repository, even if those changes are not reflected in the normal commit history.Reflog stands for "reference log." It records when the tip of branches or other references (like HEAD) is updated in your repository. Git reflog is a powerful tool in Git that keeps a record of all the changes made to the branches and commits in your repository, including actions that are not part of the regular commit history, such as resetting branches or checking out commits. It's particularly useful for recovering lost commits or understanding the history of changes in your repository, even if those changes are not reflected in the normal commit history.Reflog stands for "reference log." It records when the tip of branches or other references (like HEAD) is updated in your repository.
Learn more from the following resources: Visit the following resources to learn more:
- [@official@Git - git-reflog Documentation](https://git-scm.com/docs/git-reflog) - [@official@Git - git-reflog Documentation](https://git-scm.com/docs/git-reflog)
- [@article@What is the Git Reflog? | Learn Version Control with Git](https://www.git-tower.com/learn/git/faq/what-is-git-reflog) - [@article@What is the Git Reflog? | Learn Version Control with Git](https://www.git-tower.com/learn/git/faq/what-is-git-reflog)

@ -1 +1,8 @@
# Git Remotes # 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.
Visit the following resources to learn more:
- [@article@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)

@ -1 +1,8 @@
# git reset # git reset
Git reset is a command that allows you to "undo" or reset your current branch to a previous state by moving its HEAD pointer, effectively discarding changes made since then. When using git reset, it's essential to specify one of the three modes: soft, hard, or mixed. The mode you choose will determine how Git interacts with files in your working directory and staging area.
Visit the following resources to learn more:
- [@article@Git reset](https://www.atlassian.com/git/tutorials/undoing-changes/git-reset)
- [@video@Git Reset | How to Use Git Reset | Learn Git](https://www.youtube.com/watch?v=s1idhUiCk38)

@ -1 +1,14 @@
# git revert # 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.
Visit the following resources to learn more:
- [@article@Git Revert](https://medium.com/@meghasharmaa704/git-revert-84727b543c17)
- [@video@Git Revert - Visualised](https://www.youtube.com/watch?v=XJqQPNudPSY)

@ -1 +1,14 @@
# Git Stash Basics # 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.
Visit the following resources to learn more:
- [@article@Git stash](https://www.atlassian.com/git/tutorials/saving-changes/git-stash)
- [@article@A practical guide to using the git stash command](https://opensource.com/article/21/4/git-stash)

@ -1 +1,12 @@
# Git vs Other VCS # 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.
Visit the following resources to learn more:
- [@article@Git vs. Other VCS: A Comparative Analysis](https://medium.com/@pascalchinedu2000/git-vs-other-vcs-a-comparative-analysis-5cb03ad58e0e)

@ -1 +1,8 @@
# Git Worktree # 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.
Visit the following resources to learn more:
- [@article@Git Worktree](https://www.gitkraken.com/learn/git/git-worktree)
- [@video@Manage Branches easily using Git Worktree](https://www.youtube.com/watch?v=cRunWRC8ye0)

@ -1 +1,3 @@
# Staged Changes # Staged Changes
To view the changes you've staged with `git add`, but not yet committed, use `git diff --cached`. This command compares the staged files against their original versions in the repository. It's a quick way to review what you're about to commit before finalizing it.

@ -1 +1,6 @@
# Unstaged Changes # Unstaged Changes
For changes that are not yet staged with `git add`, such as untracked new files or modified existing ones, use `git diff --unified`. This command compares your working directory against the latest committed version of each file. It's a useful tool for reviewing any local modifications before deciding whether to stage them for future commits.
- [@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)
Loading…
Cancel
Save