Git 101 for Beginners: Learn Git Commands, Branching, and Collaboration
Tags: git, github, beginners, gitlab
Published: 2024-05-18 14:51:02

You just got your first internship at a big shot startup, it's your first day on the job and you walk in with a bag full of enthusiasm and a head full of coding dreams, really excited to work with the few of the greatest minds of the century and build software that will put man on mars only to realise that version control is a myth in this realm.



Your manager approaches you, hands you a pendrive and says, "Welcome to the team! Here's the latest version of our codebase, or maybe I think it is". You plug in the USB drive only to be greeted by folders like version_final, version_final_v1, final_final_v2. You see everyone taking turns at a computer fixing their code directly on the production server.



You take a deep breath and somehow muster up the courage to go talk to your manager and tell them about version control and git. 

"Git? Isn't that just another buzzword? We've been doing fine without it so far."

*sigh* 

"I thought so too, but hear me out..."

"Alright, you got 5 minutes"



# What is version control and git?

More than just a buzzword, git is a powerful tool that allows developers to track changes, collaborate seamlessly, and maintain a clear history of our codebase. It prevents the scenarios which causes conflicting file versions and lost changes. 

With git, each developer gets a copy of their own codebase. They can make changes, try out new experiments and even work offline or async. When they are ready, they can push their changes to a central repository, where your peers can review your code and merge it in the main branch of the central repository for it to be available to everyone else working on the same codebase. They can then pull those changes to their local codebase preventing any version mismatch and lost changes. It's like a safety net for the codebase.

*Push? Pull? Repository? Merge? What are these terms you must be thinking, don't worry we'll get to everything one by one*



# Installing Git

Installation of git can vary from machine to machine depending on what operating system you are using. 

## Installing git for MacOS

### Using homebrew

You can install [homebrew](https://brew.sh/) if you already don't have it, then : 

`$ brew install git`

### MacPorts

Install [MacPorts](https://www.macports.org/) if you don't already have it, then:

`$ sudo port install git`

### XCode

If you don't want to use either of these tools to install git, then :

You can download Xcode from the Apple App Store. Apple ships a binary of git with XCode.



## Installing git for Linux and Unix

There are a lot of Linux distributions and it is easiest to install Git on Linux using the preferred package manager of your Linux distribution.

You can head to this [link](https://git-scm.com/download/linux) and checkout the command to install git according to your Linux distro.



## Installing git for Windows

You can head to this [link](https://git-scm.com/download/win) and click on the **Click here to download** button on the website. It will download the package installer, you can open that up after it's downloaded and follow along the instructions.



# The basics

## Repository

A repository is the most basic element of Git. It's a place where you can store your code, your files, and each file's revision history. Repositories can have multiple collaborators and can be either public or private. The details of a git repository are stored in a `.git` file and each and every file and folder in the same folder as the `.git` file are considered a part of that repository and their changes are tracked within that repository.

To initialise a repository, you can run the command 

```
$ git init
```

This will create a `.git` file in the current directory



## Terms related to a repository

### Branch

Branches are one of the most powerful feature of Git. With branches you can make changes to your code without it affecting the main codebase. Think of it like a tree with multiple branches growing out of it. 

The main branch or the branch with the stable production code can be thought of as the trunk of the tree. Now we want to work on a new feature without it disturbing the stable code, that's where branching comes in. If you're working on a feature X, you can create a new branch called as `feature-X` from the `main` branch, or to fix a bug you can create a branch called as `bug-fix`. It's like creating a separate workspace where you can work on and experiment with new changes without it affecting the main codebase.

You can create a new branch from an existing branch using the following command

```
git checkout -b "branch-name"
```

The `-b` flag here tells git that this is a new branch. If you want to switch between existing branches, you can run the following command:

```
git checkout "branch-name"
```



### Clone

Cloning means to download an exact copy of a repository from the server including all versions of every file and folder. To clone a repository, you can use the following command :

```bash
git clone <your-repository-url>
```



### Merge

To take changes from one branch and apply it to another branch is called merge or merging. While merging, we go to the branch we want to merge the code into and then write the merge command with the name of the branch from which we want the code to be merged. To merge two branches, you can run the following command in your terminal :

```bash
git branch # Will display a list of all the branches
> main
> *dev #the current branch
git checkout main # Switching to the branch in which we want to merge the code into
git merge dev 
```

After this, all the changes that you did in your `dev` branch will be reflected in your `main` branch.

### Pull Request

Pull requests are one of the most important features of git and are quite similar to git merge. A pull request is essentially a way to say, 'Hey, team! I've got some changes I'd like to merge into the main codebase. Can you take a look and make sure everything looks good?'. When you create a pull request, you're opening up a conversation about your changes. It's like sending an invitation to your teammates, asking them to review your work.

Pull requests also serve as a safety net. If there are conflicts or issues discovered during the review process, you can address them directly within the pull request. It's a collaborative effort to ensure that the code being merged is of the highest quality.



## CLI Commands

Now that we've covered the basics of Git and the power of branching and pull requests, it's time to dive into the nitty-gritty. Let's talk about the essential Git commands 

### git add

When you have made changes to your code and are ready to push them on to the repository you use git add. It's like saying, "Hey Git! Here are my changes, i want you to pay attention to them". You can manually select the files or folders that you want to add to your commit by using the following command

```bash
git add index.js ## Assuming index.js is the name of the file you're working on
git add server.js
git add src/ ## Using a `/` tells git to include the whole folder
```

Or,

You can let git do the job and use 

```bash
git add .
```

Using the above command tells git to add all the changes that you've made across the whole repository, so if there are a 100 files that you have changed you need not manually add all of them



### git commit

`git add` and `git commit` are like PB&J of git. Once you've staged your changes with `git add`, it's time to commit them. This is where `git commit` comes in. It's like sealing the deal, wrapping up your changes in a nice, tidy package. The command to make a commit is

```bash
git commit -m "Added Feature X"
```

The `-m` flag allows us to include a message with the commit, it's like a note to yourself and the people who are working on the same project explaining what the changes are. It's good practice to write clear and concise commit messages.



### git status

This command gives you a snapshot of the current state of the repository. It tells you which files have been modified, which ones are staged(committed, ready to be pushed) and which ones are untracked(files changed but not added via `git add` yet). You can think of it as a progress report for your code.



### git push

This command is used to push the changes from your local repository to a remote repository hosted on the cloud most probably somewhere on Github, Gitlab or Bitbucket. When you're ready to share your commits with the rest of the team you use `git push`.

```bash
git push origin main
```

By specifying the remote repository (usually named 'origin') and the branch you want to push (in this case, 'main'), you're uploading your commits to the remote repository for others to see and collaborate on.

If you're working on a new branch, let's say `feature-x` , this branch is present in your local repository but not on the origin, so if you do a `git push`, the remote will reject your push giving you the error message that the branch does not exist. To tackle this error, while making a push to a new branch we use the `--set-upstream` flag with the push, this tells git to setup a new upstream for this push. Here it is in action:

```bash
git push --set-upstream origin feature-x
```



### git pull

When you want to update your local repository with the latest changes made by your teammates, you use `git pull`. 

This command fetches the latest changes from the remote repository and automatically merges them into your current branch, syncing your work with the rest of the team.



### git fetch

This command is like having a peak into what's new in the repository without merging it to your local repository unlike `git pull` .  It allows you to review the changes and decide whether you want to merge them manually using `git merge`.



# Summary

As we've explored the world of Git, from its basic concepts to essential commands, I hope you now see the power and potential it holds for collaborative software development. Git is more than just a version control tool; it's a catalyst for teamwork, a guardian of code integrity, and a navigator through the complex landscape of project management. By mastering Git, you'll unlock a new level of efficiency and confidence in your development workflow. So, whether you're a seasoned developer or just starting your coding journey, embrace Git, and let it be your guide. Remember, with great Git comes great responsibility—the responsibility to write clean code, craft meaningful commits, and collaborate with empathy and respect. As you venture forth, armed with your newfound Git knowledge, I have no doubt that you'll leave a positive mark on every codebase you touch. Happy coding, and may your branches always merge smoothly!



## tl;dr 

- Git is a powerful version control tool that enables developers to track changes, collaborate seamlessly, and maintain a clear history of the codebase.
- Git provides each developer with their own copy of the codebase, allowing for independent work and experimentation.
- Key Git terms include repository, branch, clone, merge, and pull request.
- Essential Git commands: `git add` stages changes, `git commit` wraps up changes with a message, `git status` provides a snapshot of the repository, `git push` uploads commits, `git pull` fetches and merges changes, and `git fetch` allows previewing changes.
- Branches enable developers to work on features or bug fixes without affecting the main codebase.
- Merging and pull requests facilitate the integration of changes from one branch to another.
- Writing clear and concise commit messages is crucial for maintaining a readable and informative project history.
- Use the `--set-upstream` flag when pushing to a new branch to establish the connection between local and remote repositories.