Git Basics Explained

Do you remember the days before Google Docs, when the idea of more than one person working on the same file was bonkers? To be fair, I barely remember those days, but I do remember it being a hindrance to my elementary history projects. 

We’re used to working with other people seamlessly now, but that mostly works better for single files and Word documents - thank you Google Docs. 

But software projects and applications consist of many components; separate files, large libraries, etc. They’re also constantly being modified and often by many different people. So working with multiple developers gets a little more complicated. 

So the question is: How can you collaboratively develop a project without disturbing others also working on it? Maybe you want to go back to older versions of the project - having to undo all those changes would be tedious, and would remove them for everyone else. Or you want to add in new features; it will probably take time and testing before those features are ready for everyone to use.

The solution is version and source control, the most widely used one being Git. Which is a tool that helps developers manage changes to their code. It keeps track of all the modifications made to files in a project over time, allowing developers to collaborate effectively and revert to previous versions if needed. 

Git itself is a distributed version control system, meaning it is used to store and track projects locally on a developer's computer. Version control platforms, such as GitHub, are where projects and repositories are stored remotely for developers to access and collaborate on; whether it’s a private development team or open source.

Key Concepts

Repository (Repo):

A repository, or repo for short, is like a folder that contains all the files for a project. It's where Git stores the history of changes made to the project.

Branch:

• A branch is a separate line of development within a repository. Think of it as a copy of the repo, where developers can work on new features or fixes without affecting the main project. 

Commit:

• A commit is a snapshot of the project at a specific point in time. Each commit marks all changes that have been made to the repository since the last commit. It’s best to make frequent and small commits to keep track of progress and easily revert to previous versions if needed.

Merge:

• Merging is the process of combining changes from one branch into another. Typically it’s used to incorporate changes made on one of the development branches back into the main branch of the project.

Pull Request / Merge Request:

• Pull requests and merge requests are essentially the same thing and are a way to propose and make changes to a repository. There are some methodological differences but the main difference is which version control platform is in use. When a pull or merge request is created, developers of a project can discuss and review the proposed changes before they're merged into the main branch.

Basic Workflow:

Initialize a Repository:

• To start using Git version control, the first step is to initialize a repository in your project directory. In a terminal window at your project's directory location, run the inti command to tell Git to create the necessary files and folders to start tracking changes in your project.

git init 

Clone a Repository: 

• To start working on a project that is stored on a remote repository or to make a copy of an existing repo in a new directory, clone the repo to create a local version. Cloning a project will copy all files in the project directory as well as all the committed revision history and existing branches

git clone <url or path to repo>

Add Changes:

• Git does not automatically add the changes made to files to the version control history. After making changes to files, stage them for commit using the add  command. This tells git what changes should be tracked and included in the next commit

git add <filename>

• You can add changes from individual files or to add changes in multiple or new files use

git add --all
 - or - 
git add .

Commit Changes

•  Once changes are staged, create a commit to save those changes to the repository. Adding a message to briefly summarize the changes made in each commit helps track work and communicate with other developers working on the same project.

git commit -m "Your commit message"

Create and Switch Branches:

• Each project has a main branch, but to create a new feature or fix a bug, you can create a new branch to develop on using:

git checkout -b <branch-name>

• Then, switch between branches using the same command with out the '-b' flag

git checkout <branch-name>

Merge Changes:

• When development work on one branch is completed, switch to the main or another upstream branch where the changes should be combined, and merge the development branch using:

git merge <branch-to-be-merged> 

Push Changes:

• All these git actions so far manipulate your local version control. To collaborate with others or when using a remote repository like GitHub, “push” changes, merges, new branches, etc. to the remote repository using git push. So that any updates are available to everyone working on the project.

git push

Pull Changes:

• The reverse of pushing changes, if others have made changes and pushed to the remote repository, you can pull those changes down to your local repository using:

git pull

Conclusion:

Git provides a powerful set of tools for managing code changes, collaborating with others, and maintaining project history. We’ve only scratched the surface here there’s a never-ending ecosystem of tools and integrations, but by understanding the basic concepts and workflows of Git, you’re on your way to developing more efficiently and effectively.