Git Basics

Git is currently the most popular used distributed Version Control System (VCS), meaning that your source code is stored in a version control repository. These local (offline) or remote (online) repositories make it easy to manage your source code.

Source code is first committed locally, and then can be sync'ed with a remote repository. Git is a popular choice for many individual developers and organizations. Most major development environments and operating system support the Git command line tools and services.


Git Basics: Every time your source code is saved to Git, it is known as a 'commit'. A commit is a snapshot of all your files at a point in time. If a file has not changed from one commit to the next, Git will use the last stored version of a file. A code commit creates a link to other commits, forming a timeline of your development history . It is possible to revert your code to a previous commit, and inspect how files changed between commits, and review where and when changes were made. Commits are tracked in Git using a unique cryptographic hash of the contents of the commit that were made. Since everything is hashed, it is not impossible for changes to be made, or information to be lost or corrupted without Git being able to detect it.


Branches: When developing code, each developer will save changes into their own copy of a local code repository. This allows for many different changes to be made to the source based off the same commit. Git provides tools for isolating changes and later merging them back together. Branches, are lightweight pointers to work in progress. Once the work has been completed in the branch, it can be merged back into branch that is being worked on. In most situations, you may have development, staging, and master branch, but depending on the structure of the organization.


Files & Commits: Files in Git can be in one of three states: modified, staged, or committed. When a file is first created or modified, it only exists in the local working directory. It is not yet part of a commit or the rest of the source code development history. The changed file(s) must be staged if it needs to be included in next commit. Once the files are staged, a copy of all changes in the files will be included in next commit to the source repository. Once the staged file(s) are committed (generally with a message describing the change), they will be ready to be 'pushed' into a sub-branch (aka 'feature branch') off the one of the main branches (i.e. development, staging, or master). When the developer is ready to commit the changes to the source code into the central repository, that is when you do a push which makes them a part of the development history.


Note:

It is best practice, break large changes into a series of smaller commits to make it easier for other developers to review and understand the changes that were made to a specific file.

=====

Benefits of Version Control System


Advantages of Git: Using Git with a source code management tool can help increase team collaboration, enforcing policies, automating processes, and improving visibility and traceability of work.


Simultaneous Development: Every developer has their own local copy of the source code and can work simultaneously on their own copies of the branches of the repository. Git allows developers to work offline since almost every operation is local.


Faster Releases: Branches allow developers to work simultaneously on different development projects. The master (or production) branch contains stable, high-quality code from the different releases. Feature branches contain development in progress, which can be merged back into the main branch upon completion.


Built-in Integration: Due to its popularity, Git is integrated into most tools service and products. Most major IDEs has built-in Git support, and many tools that allow you to manage continuous integration, continuous deployment, automated testing, work item tracking, metrics, and reporting feature integration with Git. This integration simplifies your day to day workflow.


Strong Community Support: Git has become the de facto standard for version control system for open-source and closed-source projects. With strong community support there is also no shortage of third party tools and information resources available to help your organization.


Pull Requests: It is possible to use Pull Requests (PR) to review code changes with the team before they can be merged back into your main branch. The discussions you have in pull requests are valuable for ensuring code quality and sharing knowledge across the team.


Branch Policies: Allows the enforcement of consistent workflows and processes across your team, by setting up branch policies to ensure that PRs meet your organization's requirements before code completion. Branch policies can protect your source code by preventing direct pushes, requiring reviews, and help ensure clean builds.

Visualization of the "history tree" of a revision controlled project (Attribution)

====

More information: