Just Git like a pro

In the ever-evolving world of software development, managing code changes is paramount. This is where Version Control Systems (VCS) come into play. A VCS is a system that tracks changes made to files over time, allowing developers to revert to previous versions, collaborate efficiently, and maintain a clean history of their project's evolution. Using a VCS can require some special tips and tricks to consider.

What are Version Control Systems

At its core, a Version Control System is a tool that records changes to a file or set of files over time, enabling you to recall specific versions later. In a version control we take snapshots of changes brought to our code overtime and each snapshot identify by a message and its meta data.

Types of VCS

VCS exiting in two main types: Centralized VCS and Distributed VCS. Let's hear more from this.

Centralized Version Control System (CVCSs)

These are VCS that rely on a centralized server to store all versions of a project's files. While this setup simplifies the versioning process for many scenarios, it also introduces a single point of failure. If the server goes down or the repository is corrupted, the history of the project could be lost. Some of which include the SVN.

Distributed Version Control Systems (DVCS)

Just like Git and Mercurial, allow multiple copies of the entire repository to exist simultaneously on different systems. This methodology not only provides a backup but also enables more flexible collaboration and branching strategies.

Why Git is best?

Git, created by Linus Torvalds in 2005 for Linux kernel development, has become the de facto standard for distributed version control. Its popularity stems from its robustness, flexibility, and efficiency in handling projects of any size. Unlike CVCS, Git's distributed nature allows every contributor to have a full copy of the project's history, making operations like branching and merging faster and reducing reliance on a central server. Git is a free and open-source DVCS that efficiently handles small to very large projects with speed and accuracy. It's designed to handle everything from small to very large projects with speed and efficiency. Git enables multiple developers to work together on the same project without stepping on each other's toes. It’s a system that records changes to a file or set of files over time so that you can recall specific versions later.

Git features

Git provides features like:

• Branching: Allows creating isolated copies of the codebase for independent development, perfect for bug fixing and feature implementation.
• Merging: Combines changes from different branches back into the main codebase. Version tracking: Maintains a complete history of all changes, enabling reverting to previous states and reviewing code evolution.
• Collaboration: Enables seamless collaboration among developers by allowing them to share their branches and merge changes easily.

Let's dive in (Customizing your Git experience) 🚀

Now let do something cool, customizing some experience we have in git and doing some ease configurations to ease our experience with git VCS.

Setting Global Git Configurations:

Let's explore some custom configuration, some of which are necessary and others are all optional.

# command you must run
git config --global user.name "Your Name"
git config --global user.email "[e-mail]"

# optional: beautifying
git config --global color.status.added green
git config --global color.status.changed yellow

# Configure default branch
git config --global init.defaultbranch main

Ignoring files globally

Create a .gitignore file in your home directory to specify files or folders you don't want Git to track. Common examples include:

# for Linux or bash terminals
touch .gitignore

After creation you can open and drop whatever content you want in there.

Secure Collaboration with SSH and GPG:

Secure Shell (SSH) is a protocol used to securely log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides a secure channel over an unsecured network in a client-server architecture.

GitHub and other platforms use SSH keys to securely communicate with your machine. To handle multiple accounts on a single PC, you can generate separate SSH keys for each account and add them to the SSH agent. This setup involves creating a config file for SSH to manage these keys efficiently.

ssh-keygen -t rsa -b 4096 -C "[e-mail]"

• Next step to follow will be on GitHub

GNU Privacy Guard (GPG):

This is a tool for encrypting and signing your data and communications. GitHub uses GPG signatures to verify that commits and tags are created by a specific account. Configuring GPG involves generating a GPG key pair, adding the GPG key to your GitHub account, and configuring Git to use your GPG key for signing commits and tags.

By understanding and implementing these configurations, developers can enhance their Git experience, ensuring efficient and secure management of projects. Git's flexibility and robustness, combined with its ability to be customized to fit any development workflow, make it an unparalleled tool in the arsenal of modern developers. Whether you're working on a small project or a massive enterprise, mastering Git and its configurations is a step toward professional growth and enhanced collaboration in the software development world.

Let's do that:

# install gpg and generate a key pair
gpg --gen-key

# configure git to use it
git config --global user.signingkey your_key_id

• Next on GitHub

These configurations, however, are specific to a single GPG key. To manage multiple accounts on a single PC, consider using tools like gpg-agent and dedicated configuration setups for each account.

SSH and GPG Configuration for Multiple Git Accounts

• For each account from remote VCS create an SSH and GPG using the previously given commands.
• Create or modify the ~/.ssh/config file to add configurations for each Git account. Here's an example setup for GitHub:

# Account 1
Host github.com-account1
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_account1

# Account 2
Host github.com-account2
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_account2

Replace id_rsa_account1 and id_rsa_account2 with the actual file names of your SSH keys. Remember to use the name without .pub, the .pub will be dropped entered on GitHub.

• As for the GPG we will play a little around with the .gitconfig file at the home of your directories.
  • For each remote VCS account you are use, you need a configuration file for it.
  • Each account should have a folder which becomes that account default working directory.
  • These are some measures we take in order to play around with git conditioning.

A Sample of my .gitconfig file:

[init]
  defaultBranch = main

[commit]
  gpgsign = true

[includeIf "gitdir:~/Work1/"]
  path = ~/.gitconfig.work1

[includeIf "gitdir:~/work2/"]
  path = ~/.gitconfig.work1

[includeIf "gitdir:~/Personal/"]
  path = ~/.gitconfig.personal
[push]
        default = current
        autoSetupRemote = true
[core]
        excludesfile = ~/.gitignore_global

The default value for excludesfile is .gitignore.

Summarize

Table 1: Types of Version Control Systems Comparison

Feature	CVCS (e.g., SVN)	DVCS (e.g., Git, Mercurial)
Architecture	Centralized repository	Distributed repositories
Access Speed	Fast for centralized access	Fast for local operations
Internet Connection Required	Yes, for most operations	No, for most operations
Collaboration	Managed through central server	Peer-to-peer collaboration
Branching and Merging	Possible but less efficient	Highly efficient
Backup and Restore	Single point of failure	Every clone is a full backup
Learning Curve	Moderate	Steep for beginners
Use Case	Small to medium teams/projects	Any size team/project

Table 2: Git Features Summary Comparison

Feature	Git	SVN	Mercurial
Type	DVCS	CVCS	DVCS
Branching & Merging	Easy and fast	More complex and slower	Easy but slightly less efficient than Git
Local Operations	Almost all operations are local	Limited	Most operations are local
Storage Efficiency	Highly efficient (compression)	Less efficient	Efficient but less so than Git
Network Performance	Excellent (fetch/push what's needed)	Can be slower	Very good
Integrity	SHA-1 hash for content identification	Relies on revision numbers	SHA-1 hash for content identification
Staging Area	Yes (index)	No	No
Learning Curve	Steep	Moderate	Moderate
Community and Support	Extremely large and active	Large	Large but smaller than Git

My POV

In summary, the dominance of Git in the software development world is a testament to its flexibility, power, and the vibrant community that supports it. Whether you're working on open-source projects or enterprise software, Git provides the tools and ecosystem to manage your codebase effectively, making it an indispensable tool for modern software development.

For the curious ones

Let's wrap up with this

The evolution from Centralized to Distributed Version Control Systems (VCS), particularly with Git's ascendancy, marks a significant milestone in software development, offering unparalleled flexibility, robustness, and efficiency in managing codebases. Git not only revolutionizes collaboration through its distributed nature and integration with platforms like GitHub, GitLab, and Bitbucket but also caters to a wide range of project sizes with its superior handling of branches, merges, and local operations. Mastering Git's complexities unlocks its full potential, enhancing code quality, project manageability, and collaboration. As a cornerstone of modern software development, Git's widespread adoption underscores its indispensable role in facilitating dynamic development workflows and community-driven innovation.

Comments

[Paul J. Lucas]

Git provides features like:

The features you list are also provided by most other VCSs. You're making it seem like those features are unique to git — they're not.

You mention .gitignore, but you neglect to mention that you can also have .gitignore files on a per-project and per-directory-per-project basis.

You give global configuration for git, but you don't give any examples of actually using git to create a repo, clone a repo, branching, merging, etc.

[Steve Yonkeu]

Right!
Git, as a Version Control System (VCS), uniquely offers a distributed architecture, enabling each user to have a complete local copy of the entire project history, providing robustness and flexibility in managing branches and merging changes. Its emphasis on non-linear development through thousands of parallel branches, powerful merge capabilities, and the ability to handle large projects with speed and efficiency set it apart. Additionally, Git's data integrity feature, where every file and commit is checksummed, ensures the integrity of the project history, making it distinct among VCS options.

Will do the necessary adjustments.

[Paul J. Lucas]

Git, as a Version Control System (VCS), uniquely offers a distributed architecture, ...

No it doesn't. Mercurial is also distributed, so git can't uniquely offer a distributed architecture.

[Steve Yonkeu]

Git uniquely offers a precise staging area, efficient DAG-based storage, powerful rebase feature, and a vast ecosystem of tools and integrations.

[Paul J. Lucas]

• You assume that a typical user knows what a "precise staging area" is.
• Why should a user care that it uses DAG-based storage?
• You assume that a typical user knows what a "rebase feature" is.

For all those points, you assume that a typical user knows why those things are "better." It would be like me saying "cars from Company X offer precise frabnoozles, efficient whozawhats, and a powerful gebholtz feature." Without knowing what those terms mean, the statement is meaningless. You need to explain what those git features are any why anybody should care.

[Wesley Schwengle]

I don't like your multi-account setup if honest. It is a less-than-optimal solution.

[Steve Yonkeu]

So what are your suggestions ?

[Wesley Schwengle]

I think you should change core.sshCommand in your git projects. You can do this by organising your projects in such a way that you use an includeIf based on the gitdir you are in. If you want the specifics, see this blogpost

[Steve Yonkeu]

So you mean setting up the configuration in such a way we use this command?

GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa_example" git clone [e-mail]:repo.git

[Wesley Schwengle]

Yes, you are going to configure the GIT_SSH_COMMAND in your git config and if you correctly organise your projects you can use any forge by selecting the correct ssh key and you can even, with a little shell script do it within repo's depending on the remote.

[Steve Yonkeu]

Sounds interesting as suggestion, will be best to avoid looping through the existing keys trying to find one.

But if you look closely, you will notice there is a change in the origin I use to clone the repos.

Take for example, to clone a personal repo I'll do the following:

# the gitconfig to be used

# for personal user
Host github.me

  HostName github.com

  User yokwejuste

  IdentityFile ~/.ssh/personal

Then upon cloning the repo, I'll use:

# using this
git clone [e-mail]:unstructuredstudio/zubhub.git

#instead of this
git clone [e-mail]:unstructuredstudio/zubhub.git

Having a close look at the ssh url, we can see a change from .com => .me

[Wesley Schwengle]

Yes, as mentioned, you would use: sshCommand = -i ~/.ssh/id_client -o IdentityOnly=yes -F /dev/null:

The identityOnly=yes is only there to prevent ssh from looping over all your ssh-keys and potentially using a different ssh key. The -F /dev/null disables using your .ssh/config. You could also use a different SSH config for just the sshCommand, e.g. sshCommand = -F ~/.ssh/config-client and set the correct ssh options in that file.

I know what you are saying, but the problem is that you now need to change all the hostnames when cloning other remotes, upstream, yours and others depending on the size of your (project) team.

[Steve Yonkeu]

Inputing the ssh identity file can be more effective in terms of performance at the end.

Thanks again for this.

[Fatemeh Paghar]

he key advantages of utilizing a Distributed Version Control System (DVCS) like Git over a Centralized Version Control System (CVCS) like SVN are multifaceted. Firstly, DVCS allows each developer to have a complete copy of the project's repository, enabling them to work independently without constant reliance on a central server. This decentralization not only enhances flexibility but also mitigates the risk of a single point of failure, as seen in CVCS. Additionally, DVCS facilitates more streamlined collaboration by offering features like branching and merging, which are faster and more efficient compared to CVCS. Branching in Git, for instance, allows developers to create isolated environments for experimentation or feature development, which can later be merged back into the main codebase seamlessly. Moreover, DVCS promotes a more distributed workflow, making it easier for teams distributed across different locations to work together effectively. Overall, the distributed nature and robust feature set of DVCS like Git make it the preferred choice for modern software development projects over traditional centralized systems like SVN.

[Manka Velda]

Interesting 👍👩‍💻
I thought I knew git until this 😅
Thank u

[Steve Yonkeu]

💡 you're welcome

[Jemendieta]

Thank U

[Steve Yonkeu]

You're welcome

[Jean-Michel 🕵🏻‍♂️ Fayard]

Git is the best because everyone else uses it.

On the merits, I'm not convinced. One of my most contentious hot takes here is that git is not the end of history

Git is very flexible but poorly optimized for the kind of workflow my team work on and thus has a big tendency to get in the way.

[mfalconi]

what does your team use for version control?

[Jean-Michel 🕵🏻‍♂️ Fayard]

We use git because that's what everyone (the colleagues, GitHub, the CI, ...) is using and there is lots of value in that.

On the other hand, I feel totally free to disregard so called "git best practices" whenever they don't serve us but instead slow us down. git is just a tool, not the actual work we are trying to do.

[Dima Sukharev]

in case you want a tool to generate a commit message: dev.to/disukharev/opencommit-featu...