DEV Community

Cover image for Just Git like a pro
Steve Yonkeu
Steve Yonkeu

Posted on

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

Thinking Badman
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?

thinking man

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 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) πŸš€

Diving person
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 "your_email@example.com"

# 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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 "your_email@example.com"
Enter fullscreen mode Exit fullscreen mode
  • Next step to follow will be on GitHub Adding ssh to 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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (24)

Collapse
 
pauljlucas profile image
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.

Collapse
 
yokwejuste profile image
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.

Collapse
 
pauljlucas profile image
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.

Thread Thread
 
yokwejuste profile image
Steve Yonkeu

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

Thread Thread
 
pauljlucas profile image
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.

Collapse
 
waterkip profile image
Wesley Schwengle

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

Collapse
 
yokwejuste profile image
Steve Yonkeu

So what are your suggestions ?

Collapse
 
waterkip profile image
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

Thread Thread
 
yokwejuste profile image
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 git@example.com:repo.git
Enter fullscreen mode Exit fullscreen mode
Thread Thread
 
waterkip profile image
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.

Thread Thread
 
yokwejuste profile image
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
Enter fullscreen mode Exit fullscreen mode

Then upon cloning the repo, I'll use:

# using this
git clone git@github.me:unstructuredstudio/zubhub.git

#instead of this
git clone git@github.com:unstructuredstudio/zubhub.git
Enter fullscreen mode Exit fullscreen mode

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

Thread Thread
 
waterkip profile image
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.

Thread Thread
 
yokwejuste profile image
Steve Yonkeu

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

Thanks again for this.

Collapse
 
fpaghar profile image
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.

Collapse
 
mankavelda profile image
Manka Velda

Interesting πŸ‘πŸ‘©β€πŸ’»
I thought I knew git until this πŸ˜…
Thank u

Collapse
 
yokwejuste profile image
Steve Yonkeu

πŸ’‘ you're welcome

Collapse
 
jemendieta profile image
Jemendieta

Thank U

Collapse
 
yokwejuste profile image
Steve Yonkeu

You're welcome

Collapse
 
jmfayard profile image
Jean-Michel πŸ•΅πŸ»β€β™‚οΈ Fayard • Edited

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.

Collapse
 
mfalconi profile image
mfalconi

what does your team use for version control?

Collapse
 
jmfayard profile image
Jean-Michel πŸ•΅πŸ»β€β™‚οΈ Fayard • Edited

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.

Collapse
 
disukharev profile image
Dima Sukharev

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

Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more