Introduction to Source Code Management

Introduction to Source Code Management

Source Code Management is the process of tracking and controlling changes made to a software project's source code. It helps developers and other stakeholders to see a complete history of all changes made to a shared codebase.

There are 2 types of Source Code Management (SCM)

  • Centralized Version Control System (CVCS)

  • Distributed Version Control System (DVCS)

Let's see the difference between CVCS and DVCS.

Centralized Version Control System (CVCS)Distributed Version Control System (DVCS)
1) In CVCS, a client needs to get a local copy of the source from the server, make the changes and commit those changes to the central source on the server.1) In the DVCS, each client can have a local branch as well and have a complete history on it. The client needs to push the changes to the branch then it'll be pushed to the server.
2) CVCS systems are easy to learn and set up.2) DVCS systems are difficult for beginners. Multiple commands need to be remembered.
3) Working on Branches is difficult in CVCS. Developers often face merge conflicts.3) Working on branches is easier in DVCS. Developers face less conflict.
4) The CVCS system does not provide offline access.4) DVCS systems are working fine in offline mode as a client copies the entire repository on their local machine.
5) CVCS is slower as every command needs to communicate with the Server.5) DVCS is faster as most user deals with a local copy without hitting the server every time.
6) If the CVCS server is down, the developer cannot work.6) If the DVCS server is down, the developer can work using their local copies.
7) An example is SVN.7) An example is GIT.

Introduction to GIT

GIT has 3 stages

  • Untracked: Files that exist in the working directory but are not yet tracked by Git.

  • Staged: Files that have been added to Git but have not yet been committed.

  • Committed: Files that have been committed to the repository.

We can use the git status command to see a list of all the files in each stage.

A staging area is a place where you can temporarily store changes that you want to commit to the repository. You can add files to the staging area by using the git add command. Once you have added a file to the staging area, you can commit it to the repository by using the git commit command.

The three stages of Git represent the different states that a file can be in in a Git repository. Untracked files are files that are not yet under version control. Staged files are files that have been added to the repository but have not yet been committed. Committed files are files that have been saved to the repository and can be retrieved at any time.


A Few Terminologies of GIT

  1. Repository

    • A repository is a place where you have all your codes or kind of folder on the server.

    • It is a kind of folder related to one product.

    • Changes are personal to that particular Repository.

  2. Server

    • It stores all repositories.

    • It contains metadata also.

  3. Working directory

    • Where you see files physically and do modifications.

    • At a time, you can work on a particular branch.

  4. Commit

    • Store changes in the repository. You will get one commit ID.

    • It is 40 alphanumeric characters.

    • It uses the SHA-1 checksum concept.

    • Even if you change one dot, the commit ID will get changed.

    • It helps you to track the changes.

    • Commit is also named as SHA-1 hash.

  5. Commit-ID/Version-ID/Version

    • Reference to identify each change.

    • To identify who changed the file.

  6. Tags

    Tags assign a meaningful name with a specific version in the repository. One tag is created for a particular save, even if you create a new commit, it will not be updated.

  7. Snapshots

    • Represents some data of a particular time.

    • It is always incremental i.e. it stores the changes (appended data) only not the entire copy.

  8. PUSH

    • Push operations copy changes from local repository instances to a remote or central repo. This is used to store the changes permanently in the git repository.
  9. PULL

    • Pull operation copies the changes from a remote repository to a local machine. The pull operation is used for synchronization between two repos.
  10. BRANCH

    • The product is the same, so one repository but a different task.

    • Each task has one separate branch.

    • Finally, merge (code) all branches.

    • Useful when you want to work parallelly.

    • Can create one branch based on another branch.

    • Changes are personal to that particular branch.

    • The default branch is 'Master' or 'Main'

    • The file created in the workspace will be visible in any of the branch workspaces until you commit. Once you commit then that fi;e belongs to that particular branch.


Advantages of GIT

  • It is free and Open Source.

  • Fast and Small-> As most of the operations are performed locally, therefore it is fast.

  • Security-> Git uses a common cryptographic hash function called hash function (SHA1) to name and identify objects within its database.

  • No need for powerful hardware.

  • Easier Branching-> If we create a new branch it will copy all the codes to the new branch.


Types of Repositories

  1. Bare Repositories (Central Repo)

    • Store and Share only

    • All Central Repositories are Bare Repo.

  2. Non-Bare Repositories (Local Repo)

    • Where you can modify the files

    • All local repositories are non-bare Repo.

Did you find this article valuable?

Support DevOps and Cloud Computing by becoming a sponsor. Any amount is appreciated!