Must know about Version Control Systems - Git #1

Minimal and knowledge on Version control systems.

This blog aims to share minimal and must-know knowledge on version control systems. This is not a tutorial vs documentation vs guide on Version control systems.

Yes, the Journey from writing code and making it live in production is fun However when more than one developer is working on code, we have to take care of code management

One part of code management is Version Control.

Code Management is a big topic, this blog only covers Version control. We will cover more topics in Future Blogs. Subscribe to the blog to get updates

Quick Definition:

Version control is a mechanism that keeps track of modifications made to a single file or a group of files throughout time, enabling you to retrieve specific versions when necessary.

Topic 1: Open Source version control systems available

The most used version control system in Industry is Git. But there are more VCS(version control systems) available in the market.

1. Git: https://git-scm.com/

2. Subversion (SVN): https://subversion.apache.org/

3. Mercurial: https://www.mercurial-scm.org/

4. Bazaar: https://bazaar.canonical.com/en/

5. CVS: https://www.nongnu.org/cvs/

6. Perforce: https://www.perforce.com/products/perforce/version-control-system

7. Darcs: https://darcs.net/

8. Fossil: https://fossil-scm.org/

9. GNU RCS: https://www.gnu.org/software/rcs/

10. Monotone: https://www.monotone-ng.com/

Comment below if you need a seperate blog on each of these Version control systems

Topic 2: Git v/s Github

Git

Git is a tool that helps developers keep track of changes to their code over time. It allows them to create different versions of their code, called "branches", and merge them when they are ready.

Git is installed on a developer's computer and can be used with or without an internet connection. It's like a time machine for code that makes it easy to experiment and collaborate with others.

Github

GitHub is a website that provides a central location for developers to store and share their Git repositories. It offers tools for collaboration, code review, and project management, and makes it easy to contribute to open-source projects.

GitHub allows developers to showcase their work and collaborate with others by sharing code and making it accessible to the wider community. It's like a social network for developers that makes it easy to share and work on code with others.

To summarize, Git is a version control system, while GitHub is a web-based platform for storing and sharing Git repositories.

Topic 3: Must know Git commands

1. git init:

   1. Initialize a new Git repository in a directory i.e. Start a new Git repository in a folder on your computer.

   2. To create a new Git repository in a directory, navigate to the directory in your command line and type git init.

2. git clone:

   1. Clone an existing Git repository to a new directory i.e. Copy an existing Git repository from a remote server to your local computer.

   2. To clone an existing Git repository to your local computer, navigate to the directory where you want to clone the repository and type git clone [repository URL]. For example, if you wanted to clone the Git repository for the popular Python library requests, you would type git clone https://github.com/psf/requests.git. This will create a new folder called requests your current directory, containing a copy of the repository.

3. git add:

   1. Stage changes to be committed. i.e. Tell Git to track changes you have made to a file so that you can commit them.

   2. use git add [filename] to stage a specific file, or git add . to stage all changed files in the current directory.

4. git commit:

   1. Commit staged changes with a message describing the changes. i.e. Save the changes you have made to the repository with a description of what you changed.

   2. To commit changes with a message describing the changes, use git commit -m "commit message".

5. git status:

   1. View the status of changes in the working directory.

6. git log:

   1. To view the commit history of a repository, type git log

7. git branch:

   1. Create, delete, or list branches.

   2. To create a new branch, use git branch [new branch name]. For example, if you wanted to create a new branch called, you would type git branch dev. To list all branches, use git branch. To delete a branch, use git branch -d

8. git checkout:

   1. Switch to a different branch or commit.

   2. use git checkout [branch or commit name].

9. git merge:

   1. Merge changes from one branch into another.

   2. To merge changes from one branch into another, first switch to the branch you want to merge into (git checkout [target branch name]) and then use git merge [source branch name].

   3. For example, to merge changes from the dev branch into the main branch, you would first switch to the main branch (git checkout main) and then type git merge dev.

10. git pull:

    1. To fetch changes from a remote repository and merge them into your current branch, use git pull

11. git push:

    1. Push changes to a remote repository.

    2. To upload your local changes to a remote repository, use git push [remote name] [branch name]. For example, git push origin main would push changes to the main branch of the origin remote.

Topic 4: Git workflows

1. Centralized Workflow: This is a traditional way of version control where a central repository is used to store the code. Developers clone the codebase from the central repository, make changes, and push those changes back to the central repository.

2. Feature Branch Workflow: In this workflow, developers create a new branch for each feature or bug fix they are working on. Once the changes are complete and tested, the branch is merged back into the main codebase.

3. Gitflow Workflow: This is a way of managing multiple branches and releases. It involves two main branches: a master branch for stable releases and a development branch for ongoing development work. Feature branches are created off the develop branch, and when a feature is complete, it is merged back into the develop branch. Release branches are created off the develop branch when preparing for a new release, and hotfix branches are created off the master branch to quickly fix critical issues.

4. Forking Workflow: This workflow is often used in open-source projects, where developers create their own copy of the main codebase to make changes. They then submit a request to the main codebase to have their changes merged in.

5. Pull Request Workflow: This workflow involves creating a feature branch, making changes, pushing those changes to a remote repository, and then submitting a request to have the changes merged into the main codebase. Other developers can review the changes and provide feedback before the changes are merged into the main codebase.

Each workflow has its own advantages and disadvantages and is suitable for different types of projects and teams.

Comment below if you need a seperate blog on examples of each workflow

Topic 5: Centralized Version Control Systems (CVCS) and Distributed Version Control Systems (DVCS):

A CVCS is like a library where all the books are stored in one place. If you want to read a book, you have to go to the library and check it out. If you want to make notes or changes to the book, you have to do it in the library and then put the book back on the shelf for others to use.

In contrast, a DVCS is like having your own personal copy of a book. You can take it home and read it whenever you want, and you can make notes or changes to your own copy without affecting the original book. If you want to share your changes with others, you can make a copy of your book and give it to them, or you can send them the changes you made electronically.

Similarly, a CVCS stores all the code in one central location, and developers have to connect to the central server to access the code and make changes. With a DVCS, each developer has their own copy of the code and can make changes locally without needing to be connected to a central server. They can then share their changes with others by pushing them to a remote server or sending them directly to other developers.

Examples of Centralized Version Control Systems (CVCS) include:

1. Subversion (SVN): A popular CVCS that was commonly used before the rise of DVCS like Git.

2. Concurrent Versions System (CVS): Another popular CVCS that was widely used in the past.

Examples of Distributed Version Control Systems (DVCS) include:

1. Git: The most popular DVCS used today for version control. It is widely used in open-source projects and by many organizations for software development.

2. Mercurial: Another popular DVCS that is similar to Git in many ways, but has some different features and workflows.

3. Bazaar: A less popular DVCS than Git or Mercurial, but still widely used in some communities.