Expert Insights to Git Savvy

An introduction to Git

Git, the distributed version control system that has become ubiquitous in software development, was first created by Linus Torvalds in 2005. Torvalds was frustrated with the limitations of the centralized version control systems that were available at the time and wanted to create a system that would allow developers to collaborate on projects remotely. Git was the result of his efforts.

In the years since its release, Git has continued to evolve and improve, with contributions from developers all over the world. Today, it is the go-to choice for version control in most software development projects and has become an essential tool for collaborating on code and managing complex software projects. Git's success is a testament to the power of open-source software, and to the passion and dedication of the many developers who have contributed to its development over the years.

Distributed Version Control

Git is a distributed version control system which means that every developer has a copy of the entire codebase on their local machine. Since each developer has a local copy of the codebase, they can make changes, commit them locally, and even switch between different branches of development without needing an internet connection. This is especially useful for developers who work in remote or disconnected environments, such as on a plane or in a location without reliable internet access. Once they're back online, they can push their changes to the remote repository. This makes it easy to collaborate on code and maintain version history.

Managing Multiple Contributors

As software development projects grow in size and complexity, it becomes increasingly important to have a well-defined branching strategy to manage code changes effectively. Without a proper strategy, it can be easy to introduce bugs, slow down development, and make it difficult to manage and maintain the codebase.

Git Flow solves the problem of having an unorganized and inconsistent branching strategy in software development projects. Before Git Flow, teams would often have their own ad hoc branching strategies that made it difficult for developers to understand what code was in which stage of development, and merge conflicts were common. Git Flow standardized a set of permanent and transitory branches for features and hotfixes, making it easier for developers to collaborate and manage changes.

How the Pull Request Protects the Codebase

In modern software development, projects often have multiple contributors working on different features or fixes simultaneously. Pull Requests (PRs) help manage these contributions by allowing developers to propose changes to the codebase, and to have those changes reviewed and validated by other members of the team before they are merged into the main codebase.

A PR Gate is a mechanism used in DevOps to ensure that the merge code is validated with a build and unit tests before the PR is merged into the main codebase. This helps ensure that code quality is maintained and that no regressions or errors are introduced into the system.

How to Keep Your Repositories from Going Rogue

You have likely battled your fair share of rogue code on your hard drive. It's time to end this war once and for all! Let us explore some strategies to keep your repositories in line and prevent them from going rogue. Let's take control of our code clones before they turn to the dark side and start a war.

Folder Structure Strategy

When cloning a repository from platforms like GitHub or Azure DevOps, create a folder structure on your local machine that reflects the platform you're using. For example:

C:\GitHub\{username}\{repository}

This helps you keep track of where code is stored and avoid cluttering the file system with unorganized code.

Branching Best Practices

• Create feature branches: Always work on feature branches, never directly on develop
• Sync regularly: Keep your branches up to date with remote repository
• Fork when contributing: Create your own copy for external projects
• Pull latest changes: Regularly update your fork from original repository

Daily Workflow

• Stay current: Keep local repository synced with develop branch
• Daily updates: Update feature branch with develop at least once daily
• Never work on develop: Always use feature branches for development
• Limit conflicts: Regular syncing prevents merge conflicts

Repository Maintenance

Keeping repositories (Origin/remote and local) in sync within Visual Studio can be confusing. Visual Studio does not always update all the remote branches when they are deleted.

Command Line Solution: Use Git command line to prune deleted remote branches:

$ git remote prune origin

A quick review of your repository can help you identify potential issues that could cause headaches in the future. Here are the warning signs to watch for: