Here is part two of my article about version control. You can find the first part here.

What types of files can we keep in version control?

There are two general file types

1. Binary files (i.e exe and dll formats).

2. Text files. Text files are further divided into two categories:

1. Hand-typed text files. Such as source code developers write.
2. Generated text files such as log or configuration files.

Generally speaking, we should store in the version control only the things we as humans wrote. For example, if you wrote a C# code and then compile that code into DLL. it doesn’t make much sense to store the DLL version of the code into the version control as all the work we humans would want to do, will involve the human-readable version so we can review it, change it, etc. 

But in rare cases it might be necessary to include binary files, one example would be if the DLL file was not stored in a package management platform such as Nuget (as the best practices suggest), But you should always stop and think before storing any binaries files into your version control to make sure you are making the right choice.

In other words, in version control, it is advisable to store only human-readable files. Binary files, such as compiled code, should be carefully considered before adding them.

Ok, so what format are binary files anyway, and where do we store them?

Binary files can be executables (e.g., EXE, DLL), compressed archives (e.g., ZIP, TAR), or specific data formats relevant to the project. They are usually stored in the package management systems such as NuGet for .Net.

What is the drawback of storing binary files in a version control platform?

Some people might say, but what the harm is keeping everything in the version control and just do what you want with the files. This might not look like a terrible idea if not for the following reason: it’s wasting resources! Storing non necessary binary files in a version control platform can lead to resource wastage, both in terms of finances and brainpower.

How does Git, GitHub, Azure repos and BitBucket fit together?

Great question! Git is an open-source and free version control system. It’s the golden standard in the industry and most companies use it. However, Git in itself doesn’t not offer much services such as hosting, collaboration and code management. This is where all other players such as GitHub, BitBucket and Azure repos get in. 

The good thing is after we understand the fundamentals of using Git, switching from one platform to another should be easy as they are all using Git as their version control engine.

Git Terminology

Here I will explain some of terms that we will encounter when dealing with Git:

Repository:

 A repo contains the complete history of the project from its beginning. In other words, it’s where the snapshots of the project content reside.

Project Content Snapshot (tree):

 it’s a structure of the files and directories that represent the complete state of the project at a certain point in time.

Commit:

A commit in Git represents a delta or a set of changes made to the codebase since the last commit. It’s a record of what has been added, modified, or deleted in the project files. 

Author Identification:

Name, email address and the timestamp of the individual who made the 

changes that resulted in the project state.

Branch:

A branch is a separate line of development. You can consider them a brand new working directory, staging area  and a project history for all practical purposes. Another way to look at it is that branches are simply a pointer to a snapshot (delta) of your changes.

Committer Identification:

 The same information about the person who added this commit to the repository (which may be different from the author).

Commit message: 

Text accompanying commits usually describe the purpose of the change.

Git workflow

Working directory: 

• This is where you have your actual files and where you work. It’s basically your project folder on your computer.
• When you start working on a project, you make changes in your working directory such as editing, adding, or deleting files.

Staging Area (Index):

• Staging area is the middle ground between your work directory and the committed changes. You can selectively stage specific changes without committing everything.

Local repo: 

• The local repository is where all your committed changes are stored on your local machine. When you make a commit, it gets saved in the local repository.
• Commits in the local repository are snapshots of your project at a specific point in time, and they can be used to track the history of your project.

Remote Repository:

• The remote repository is a version of your project that is hosted on a remote server (like GitHub, GitLab, or Bitbucket). It acts as a centralized location where multiple collaborators can contribute to the project.
• After you’ve committed changes to your local repository, you may want to share your work with others or keep a backup of your code on a remote server.
• You can push your committed changes from the local repository to the remote repository, or you can pull changes from the remote repository to your local repository.

Main Git Commands

git init:

 It initializes a new git repo in your current directory/folder. It creates a hidden subfolder within your existing project that includes the required data structure required for version control.

git add: 

This command will move your changes to the staging (index) area. You use this command to tell Git what changes you are planning to include in your new commit.

git commit:

git commit will save the changes you selected in the previous command in your local repo. Each commit has a unique identifier that includes information about who made the changes and when.

git push:

This will upload the content of your local repo to a remote repo. You will need to configure the remote repo before executing this command.

git fetch:

Similar to git push; git fetch retrieves changes from a remote repo but does not merge them automatically into your working branch. It can be used to see what others have been working without affecting your local branch. 

git checkout:

Use this command when you want to switch between different branches in your repo.

git merge:

Use this command to merge the changes from one branch to another. It combines all the changes and creates a new commit that represents the new merged git state.

The diagram below visualizes some of the concepts we discussed here.

This was a quick introduction to the world of Git, I am hoping you found some value while reading this article. Feel free to comment if you have any feedback and thank you for your time!

References:

1. Radwan, Mohamed. “Managing Version Control.” Fundamentals of Modern Software Engineering and DevOps course, Module 6. DevOps Visions. https://github.com/MohamedRadwan-DevOps/devops-step-by-step/tree/main/source/advanced-introduction-to-devops. Accessed on 8th December 2023.

2. Silverman, R. E. (2013). Chapter 1: Understanding Git. In Git pocket guide: A working introduction. essay, O’Reilly. 

3. Atlassian. “What is Version Control?” Git Tutorials. Atlassian, https://www.atlassian.com/git/tutorials/what-is-version-control. Accessed on 8th December 2023.

4. Microsoft. “Comparison of Git and Team Foundation Version Control (TFVC).” Azure DevOps Documentation. Microsoft, https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/comparison-git-tfvc?view=azure-devops. Accessed on December 9, 2023.