Getting started with Git and GitHub: the complete beginner’s guide

What GIT is about?

Git is a version control system that allows developers to track changes to their code and collaborate with others on a project. It is a tool that is commonly used in software development, as it allows developers to keep track of changes to their code, go back to previous versions if necessary, and collaborate with others on a project.

Git uses a system of "commits" to track changes to a codebase. Each time a developer makes a change to their code, they can save that change as a commit. These commits are then stored in a repository, which is a collection of commits that represent the history of a project.

Using Git, developers can work on different versions of a codebase (known as "branches") and merge those changes into the main branch of a project when they are ready. This allows multiple developers to work on a project simultaneously without interfering with each other's work.

Overall, Git is an essential tool for software developers, as it allows them to track changes to their code, collaborate with others, and maintain a high level of organization and control over their projects.

What is GitHub about?

GitHub is a platform that hosts Git repositories, allowing developers to store their code online and collaborate with others on projects. It is built on top of the Git version control system and provides a number of features that make collaboration easier, such as the ability to open and review pull requests, which are requests to merge changes from one branch into another.

In addition to hosting repositories, GitHub also provides a number of tools and features that are designed to make it easier for developers to work together on projects. This includes the ability to create issues, which are used to track tasks and bugs, and to use project management tools like Kanban boards to manage the development process.

GitHub is widely used in the software development community, and many open source projects are hosted on the platform. This makes it easy for developers to find and contribute to projects that they are interested in, and allows them to easily share their own work with others.

Overall, GitHub is an important platform for developers who want to store their code online, collaborate with others on projects, and take advantage of the tools and features that GitHub offers to make the development process easier and more efficient.

Why Use Version Control Software?

There are several reasons why developers might choose to use Git as their version control software. Some of the key benefits of using Git include:

Git allows developers to track changes to their code and go back to previous versions if necessary. This is useful for a number of reasons, such as when a bug is introduced and needs to be fixed or when new features are added and need to be tested.
Git makes it easy for multiple developers to work on a project simultaneously. Using branches, developers can work on different versions of a codebase without interfering with each other's work. This makes collaboration much easier and allows teams to work more efficiently.
Git is a distributed version control system, which means that every developer who works on a project has a local copy of the codebase. This makes it easier for developers to work offline and allows them to work more independently.
Git is open source and widely used in the software development community. This means that there is a wealth of documentation and support available, making it easier for developers to learn and use the tool.

Overall, Git is a powerful and flexible tool that offers many benefits for developers who need to track changes to their code and collaborate with others on a project.

Let’s imagine a development without version control

Without version control, software development would be a much more difficult and error-prone process. Here are a few of the challenges that developers would face:

It would be difficult to track changes to a codebase. Without version control, developers would have to manually save different versions of their code in separate files, which could quickly become difficult to manage. This would make it difficult to go back to previous versions of the code if necessary, such as when a bug is introduced or when new features are added.
Collaboration would be difficult. Without version control, it would be difficult for multiple developers to work on the same project simultaneously. This would make it hard to coordinate their efforts and ensure that their changes don't interfere with each other's work.
Projects would be more susceptible to errors and bugs. Without version control, developers would have less control over their code and would be more likely to introduce bugs and other errors into their projects. This would make it harder to maintain a high level of quality in the codebase.

Overall, the use of version control is essential for software development, as it allows developers to track changes to their code, collaborate with others on a project, and maintain a high level of control and organization over their work. Without it, the development process would be much more difficult and error-prone.

Before going any further, we need to know some basic terms…

Snapshot: In Git, a snapshot is a record of the state of a codebase at a particular point in time. Each time a developer makes a change to their code, they can save that change as a snapshot, which is stored in a repository.
Repository: In Git, a repository is a collection of snapshots that represent the history of a project. Each repository has a "head," which is the most recent snapshot in the repository.

Head: In Git, the head of a repository is the most recent snapshot in the repository. This is the snapshot that will be used when the code is checked out and run.
Branches: In Git, a branch is a separate version of a codebase that can be worked on simultaneously with the main branch of a project. This allows multiple developers to work on different aspects of a project without interfering with each other's work.
Commit: In Git, a commit is a snapshot of a codebase that has been saved to a repository. Each commit has a unique identifier and includes a message that describes the changes that were made in that snapshot.

To use Git and GitHub, a developer would first create a repository for their project. This repository would store all of the snapshots (commits) of the project's codebase. The developer would then create branches for different aspects of the project, such as new features or bug fixes.

As the developer works on their project, they would make changes to the code and save those changes as commits. These commits would be added to the appropriate branch and eventually merged into the main branch of the project when they are ready.

Using GitHub, the developer can collaborate with others on the project by sharing their repository and allowing others to contribute to it. This can be done by opening pull requests, which are requests to merge changes from one branch into another. Other members of the development team can review and comment on these pull requests before they are merged into the main branch of the project.

Overall, Git and GitHub provide a powerful and flexible set of tools for tracking changes to a codebase, collaborating with others on a project, and maintaining a high level of control and organization in the development process.

Understanding the concept of branches…

In Git, a branch is a separate version of a codebase that can be worked on simultaneously with the main branch of a project. This allows multiple developers to work on different aspects of a project without interfering with each other's work.

For example, imagine that a development team is working on a new feature for a project. One developer might create a branch for that feature, where they can make changes to the code without affecting the main branch of the project. Meanwhile, another developer might be working on fixing a bug in the main branch.

Using branches, both developers can work on their respective tasks without interfering with each other's work. When the new feature is ready to be merged into the main branch, the developer who created the branch can open a pull request, which is a request to merge the changes from the feature branch into the main branch. Other members of the development team can review and comment on the pull request before it is merged.

Overall, the use of branches in Git allows developers to work on different aspects of a project simultaneously and collaborate more effectively. This makes it possible for teams to work more efficiently and maintain a high level of control over their codebase.

To install Git on Linux, follow these steps:

Open a terminal window and run the following command to update your package manager:

Copy codesudo apt-get update

Install Git using your package manager by running the following command:

Copy codesudo apt-get install git

Once the installation is complete, verify that Git has been installed correctly by running the following command:

Copy codegit --version

If the installation was successful, you should see the version number of Git displayed in the terminal window.
To configure Git with your personal information, run the following commands, replacing the placeholder values with your own information:

Copy codegit config --global user.name "Your Name"
git config --global user.email "your_email@example.com"

Git is now installed and configured on your system. You can use Git to track changes to your code and collaborate with others on a project.

Note: These instructions are for Ubuntu and other Debian-based Linux distributions. The exact steps for installing Git on other Linux distributions may vary slightly.

Let’s GIT started

Make changes..

git add <file>: Adds a file to the staging area. This means that the file will be included in the next commit, but it has not yet been committed to the repository.
git commit -m "<message>": Commits the files in the staging area to the repository. This creates a new commit with the specified message, which includes all the changes made in the staging area.
git reset <file>: Removes a file from the staging area. This undoes the changes made to the file, and removes it from the list of files to be committed in the next commit.
git checkout -- <file>: Discards the changes made to a file in the working directory. This restores the file to the version that is currently in the repository, discarding any changes that have been made since the last commit.
git revert <commit>: Reverts the changes made in the specified commit. This creates a new commit that undoes the changes made in the specified commit, allowing you to back out changes that have already been committed to the repository.
git stash: Temporarily saves the changes made in the working directory. This allows you to switch to a different branch or work on a different task, without having to commit or discard the changes you have made.

Concept of branching

The concept of branching was thoroughly discussed in the previous article; now we will look at the commands used to put the concept into practise.

git branch <branch>: Creates a new branch with the specified name. This allows you to work on multiple features or bug fixes in parallel without affecting the main branch of the repository.
git checkout <branch>: Switches to the specified branch. This updates the files in the working directory to match the version of the code in the specified branch.
git merge <branch>: Merges the specified branch into the current branch. This combines the changes made in the specified branch with the current branch, allowing you to bring together changes from multiple branches into a single branch.
git branch -d <branch>: Deletes the specified branch. This removes the branch and all of its associated commits from the repository.
git branch -m <old-branch> <new-branch>: Renames the specified branch. This changes the name of the branch, allowing you to easily update or reorganize your branches.
git branch --merged: Shows a list of all branches that have been fully merged into the current branch. This allows you to see which branches can be safely deleted, as their changes have already been incorporated into the main branch.

Refactoring filenames
1. git mv <old-file> <new-file>: Renames a file in the repository. This automatically stages the rename for the next commit, allowing you to easily move or rename files in the repository.
2. git rm <file>: Removes a file from the repository. This permanently deletes the file from the repository, and stages the deletion for the next commit.
3. git mv <old-directory> <new-directory>: Renames a directory in the repository. This automatically stages the rename for the next commit, allowing you to easily move or rename directories in the repository.
4. git rm -r <directory>: Removes a directory and all of its contents from the repository. This permanently deletes the directory and all of its files from the repository, and stages the deletion for the next commit.
5. git mv <file> <directory>: Moves a file into a different directory in the repository. This automatically stages the move for the next commit, allowing you to easily reorganize the files in your repository.
6. git mv <directory>/* <new-directory>: Moves all of the files in a directory into a different directory in the repository. This automatically stages the move for the next commit, allowing you to easily reorganize the files in your repository.
7. git mv <file1> <file2> <file3> ... <directory>: Moves multiple files into a directory in the repository. This automatically stages the move for the next commit, allowing you to easily reorganize the files in your repository.
  
  Concluding Words
  
  Part 2 of this article is now complete. I hope you understand what GIT and GitHub are and how to use them. Keeping in mind that GIT and GitHub are vast topics that cannot be covered in a single article, I recommend that you ask any questions you may have.