Day 8: Basic Git & GitHub

What is Git?

Git is a distributed version control system for software development. Git allows multiple people to collaborate on a project by keeping track of changes made to the codebase, making it easier to merge the changes made by different people and keep a clear history of changes.

With Git, developers can work on the same project from different locations and keep their own copies of the project, which are called “repositories”. When a developer makes changes to the code, they can “commit” the changes to their local repository and “push” the changes to a central repository that is shared by the rest of the team.

This makes it possible for everyone to have access to the latest version of the code at all times.

What is Github?

GitHub is a web-based platform that offers version control hosting for software development. It is built on top of Git and provides a user-friendly interface for developers to manage their Git repositories. With GitHub, developers can store their code, track changes, and collaborate with others on projects.

What is Version Control? How many types of version controls we have?

Version control is a system that records changes to a file or set of files over time, allowing developers to recall specific versions later. The main purpose of version control is to allow multiple people to work on a project simultaneously and to keep a history of changes that have been made to the codebase. This makes it easier to collaborate on a project, revert to previous versions of the code, and track the history of the development of a project.

There are two main types of version control systems: centralized version control systems and decentralized (or distributed) version control systems.

1. A centralized version control system (CVCS) uses a central server to store all the versions of a project’s files. Developers “check out” files from the central server, make changes, and then “check in” the updated files. Examples of CVCS include Subversion and Perforce.

2. A distributed version control system (DVCS) allows developers to “clone” an entire repository, including the entire version history of the project. This means that they have a complete local copy of the repository, including all branches and past versions. Developers can work independently and then later merge their changes back into the main repository. Examples of DVCS include Git, Mercurial, and Darcs.

Why we use distributed version control over centralized version control?

1. Better collaboration: In a DVCS, every developer has a full copy of the repository, including the entire history of all changes. This makes it easier for developers to work together, as they don’t have to constantly communicate with a central server to commit their changes or to see the changes made by others.

2. Improved speed: Because developers have a local copy of the repository, they can commit their changes and perform other version control actions faster, as they don’t have to communicate with a central server.

3. Greater flexibility: With a DVCS, developers can work offline and commit their changes later when they do have an internet connection. They can also choose to share their changes with only a subset of the team, rather than pushing all of their changes to a central server.

4. Enhanced security: In a DVCS, the repository history is stored on multiple servers and computers, which makes it more resistant to data loss. If the central server in a CVCS goes down or the repository becomes corrupted, it can be difficult to recover the lost data.

Overall, the decentralized nature of a DVCS allows for greater collaboration, flexibility, and security, making it a popular choice for many teams.

GIT Cheat Sheet

git: an open source, distributed version-control system

GitHub: a platform for hosting and collaborating on Git repositories

commit: a Git object, a snapshot of your entire repository compressed into a SHA

branch: a lightweight movable pointer to a commit

clone: a local version of a repository, including all commits and branches remote: a common repository on GitHub that all team member use to exchange their changes

fork: a copy of a repository on GitHub owned by a different user

pull request: a place to compare and discuss the differences introduced on a branch with reviews, comments, integrated tests, and more

HEAD: representing your current working directory, the HEAD pointer can be moved to different branches, tags, or commits when using git checkout

Task:

1. Create a new repository on GitHub and clone it to your local machine

   

cloning the repo in my local machine

2. Make some changes to a file in the repository and commit them to the repository using Git

Added test.txt to the local machine .we can check the status with the

git status command.

added file to staging are with git add . command and then commit the changes with git commit -m "commiting test.txt " command.

3. Push the changes back to the repository on GitHub

Add a remote URL git remote add origin, then push the file to github.

git remote add origin https://github.com/Khushbu1407/Git-Hub.git

git push origin

the test.txt file is pushed to the Github repo from the local machine.