A version control system (VCS) is a tool that helps to manage changes to code. By using a VCS, you can keep track of changes made by different team members and easily roll back to a previous version if needed. Git is one of the most popular VCS tools available today.
Git can be a tricky thing to master, and can be extremely daunting for beginners. Follow this to get started - https://github.com/skills/introduction-to-github
If you are not comfortable using the terminal to work with git repositories, you can use graphical tools built to make your life easier. Some examples include GitHub Desktop and GitHub for VSCode
When you are writing any piece of code, it is always better to use a git repository to store and view changes. Think of this - did you ever write 100 lines on Jan 1st, and kept adding on to the code for a month only to realise that you broke something in the process? What do you do with broken code and no backup? DED. If you maintained a git repository, you could simply go back to your commit on Jan 1st, and see what changes have been made to that feature that caused it to break, or perhaps even simply rollback to older versions.
Each project/submodule can be stored in an encapsulated block called as a repository. A commit holds the current state of a given repository. If you make changes to code within a repository, make sure that you commit it to the repository if you are going to make changes that might break the repository!
Git repositories also have something called “branches”. Branches are basically different variants of your code that can be developed independently, and in potentially varying directions. For example, if you want to develop a new feature for your project, simply create a new branch and develop your code in that particular branch. You can later merge your branch with the main code!
Code, by its very nature will have bugs, issues, and new feature requests. Git repositories help track these issues, and allow contributors to submit pull requests with bug fixes/new features that can be directly merged with the original codebase. Hosts such as GitHub often provide a variety of neat features to make this process better. For example, you can ask a contributor (not yourself) to review your code before it is merged, and/or set up automated code checks that can perform basic checks before your code is merged. You can even set up automatic builds that can pre-compile and ensure your project is building before it is merged!
Note: Git ≠ GitHub! Git is the version management system, whereas GitHub is an online storage solution for your git repositories. There are alternatives to github as well such as GitLab, BitBucket, etc. Thus, you can store git repositories on your local machine / cloud server as well. However, for ease of use and collaboration, using a remote host such as GitHub is preferable.
Whenever you make changes to code in your local machine, your commits will reflect only on the local machine. If you wish to make these changes in your remote host as well, you should push the code to the remote origin of the repository. Similarly, if there are multiple collaborators, before you begin your work, make sure that you pull code from the repository, and merge any conflicts that may arise.
Since git can be used for collaborative coding, when merging code between different branches / authors, they may be several conflicts (i.e., one person may have changed a single line in a way that was not anticipated). Thus, before making any changes/merging branches, these conflicts must be resolved.