Many big teams use Git and GitHub as part of their software development workflow. They also power a number of well-known open-source projects. As a developer, you must get familiar with Git and make GitHub an intrinsic part of your workflow.

Introduction to Git

Git is a distributed version control system for tracking changes to files in a project. Linus Torvalds published Git for the Linux kernel in 2005. It was developed with the help of other kernel engineers, and it has since become the most common choice for software teams. Git is well-suited to non-linear development and speed.

Version control systems are a type of software that keeps track of changes to a computer program, document, or group of files. They assist a person or a group of users in tracking project changes over time.

Git saves a snapshot of the project files at a certain point in time. It saves references to files that have changed since the last snapshot, as well as files that have been updated. Because the majority of software projects are created in groups, Git is crucial.

Git is used as a repository by most organisations, large and small, including:

• Facebook
• Google
• Netflix
• Shopify

Git official homepage: https://git-scm.com/

Introduction to GitHub

GitHub is a web-based platform for storing and sharing code. Consider GitHub to be a platform for storing your whole codebase in a remote repository. It includes tools for working together on projects of any scale.

GitHub helps developers to have an uniform source of truth for their source code by allowing them to create remote repositories. It is because of this that open source is feasible.

You'll need to register a personal account on GitHub to build repositories or contribute to open source projects.

If your code is in a GitHub remote repository, follow these steps:

• Every other project contributor will be aware that they may obtain the code from the remote repository.

• Any modifications they make and want to share may be pushed to the remote repository rather than being sent to each contributor individually; GitHub acts as the project's single source of truth.

• To make development faster and more efficient, contributors and collaborators can use GitHub's project management and automation features.

1.Setup instructions

Git is mostly utilized through the command-line interface, which we may access through our system terminals. However, we must first verify that Git is installed on our machines.

You can download Git here: git-scm.com/downloads

Click the download link for your specific operating system and then follow through the installation wizard to get things set up on your computer!

After installing it, start your terminal and type the following command to verify that Git is ready to be used on your computer:

git --version

If everything went well, it should return the Git version that is installed on your computer.

• If you are using a Mac or Linux machine, then you can utilize the default Bash terminal that comes pre-installed on your machine.

• If you are using Windows, you can use its built-in Powershell terminal, or the Git Bash terminal which is bundled with the Git installation.

Configuring Your Name & Email

In your terminal, run the following commands to identify yourself with Git:

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

Replace the values inside the quotes with your name and email address.

2. Repositories

It's essential to understand the word repository while dealing with Git. A Git repository is a storage location for Git-managed projects.

Git repositories may be divided into two types:

• Local repository - a separate repository on your computer where you may work on your project's local version.
• Remote repository - often kept on a remote server outside of your isolated local system. It's extremely handy when working in groups since you can share your project code, see other people's code and integrate it into your local version of the project, and submit your changes to the remote repository from here.

Making use of Git for a new project

Let’s see how we can set up a new project using Git.

3. Initializing a repository

To begin, use the following command to establish a new directory:

mkdir Project

The next step is to go to the newly formed directory:

cd Project

Run the following command to create a git repository in this folder, which is now your working directory:

git init

Running this command in the current directory will create an empty Git repository. Git will maintain track of changes in the project by creating a new subdirectory named .git, which contains numerous files and additional subdirectories.

Let's start by making the first file we'll be tracking with Git. Make sure your terminal is still in the Project directory, then type the following command:

touch README.md

This will result in the creation of a README file with the Markdown extension.

Note - Markdown is a simple markup language that may be used to format plain text.

Most software that allows you to visually browse Git repositories (through a GUI) looks for a readme.md file and displays its contents on the project's homepage. In this file, you'd usually add information about your project, such as setup instructions.

In your editor, open the file and add the following lines:

# Project 

This is the first Git Project you've ever worked on. As we learn more about Git, we'll continue to work on this file.

This file should be saved and closed. The status of your repository should have changed once you saved the file. Run the following command to see whether this is the case:

git status

Nothing is changed or updated by this command. Rather, it shows which files have been changed, staged, or are untracked. A file that hasn't been added to the git index yet is considered untracked, but a file that has been edited since your previous commit is considered modified by git.

4. Staging and committing code

Committing is the process of 'officially' adding changes to the Git repository. Checkpoints, or snapshots of your project in its present state, are what *commits are in Git. With other words, in a commit, we simply preserve the current version of our code. We can add as many commits to the commit history as we need, and we can jump back and forth between commits to examine the different versions of our project code. This enables us to effectively monitor our efforts and track the project's development. Commits are generally made at logical moments in the development of a project, such as when particular contents, features, or adjustments have been included.

We must first place our code in the staging area before we can commit it.

4.1. Checking the status

While located inside the project folder in our terminal, we can type the following command to check the status of our repository:

git status

This is a command that is very often used when working with Git. It shows us which files have been changed, which files are tracked, etc.

We can add the untracked project files to the staging area based on the information from the git status command.

At a later point, git status will report any modifications that we made to our tracked files before we decide to add them to the staging area again.

4.2. Staging files

From the project folder, we can use the git add command to add our files to the staging area, which allows them to be tracked.

We can add a specific file to the staging area with the following command:

git add file.js

To add multiple files, we can do this:

git add file.js file2.js file3.js

Instead of having to add the files individually, we can also add all the files inside the project folder to the staging area:

git add .

By default, this adds all the files and folders inside the project folder to the staging area, from where they are ready to be committed and tracked.

4.3. Making commits

A commit is a snapshot of our code at a particular time, which we are saving to the commit history of our repository. After adding all the files that we want to track to the staging area with the **git add** command, we are ready to make a commit.

To commit the files from the staging area, we use the following command:

git commit -m "Commit message"

Inside the quotes, we should write a commit message which is used to identify it in the commit history.

The commit message should be a descriptive summary of the changes that you are committing to the repository.

After executing that command, you will get the technical details about the commit printed in the terminal. And that's basically it, you have successfully made a commit in your project!

To create a new commit, you will need to repeat the process of adding files to the staging area and then committing them after. Again, it's very useful to use the git status command to see which files were modified, staged, or untracked.

4.4. Commit history

To see all the commits that were made for our project, you can use the following command:

git log

The logs will show details for each commit, like the author name, the generated hash for the commit, date and time of the commit, and the commit message that we provided.

To go back to a previous state of your project code that you committed, you can use the following command:

git checkout <commit-hash>

Replace <commit-hash> with the actual hash for the specific commit that you want to visit, which is listed with the git log command.

To go back to the latest commit (the newest version of our project code), you can type this command:

git checkout master

4.5. Ignoring files

To ignore files that you don't want to be tracked or added to the staging area, you can create a file called .gitignore in your main project folder.

Inside of that file, you can list all the file and folder names that you definitely do not want to track (each ignored file and folder should go to a new line inside the .gitignore file).

5. Branches

A branch could be interpreted as an individual timeline of our project commits.

With Git, we can create many of these alternative environments (i.e. we can create different branches) so other versions of our project code can exist and be tracked in parallel.

That allows us to add new (experimental, unfinished, and potentially buggy) features in separate branches, without touching the 'official' stable version of our project code (which is usually kept on the master branch).

When we initialize a repository and start making commits, they are saved to the master branch by default.

5.1. Creating a new branch

You can create a new branch using the following command:

git branch <new-branch-name>

The new branch that gets created will be the reference to the current state of your repository.

It's a good idea to create a development branch where you can work on improving your code, adding new experimental features, and similar. After development and testing these new features to make sure they don't have any bugs and that they can be used, you can merge them to the master branch.

5.2. Changing branches

To switch to a different branch, you use the git checkout command:

git checkout <branch-name>

With that, you switch to a different isolated timeline of your project by changing branches.

For example, you could be working on different features in your code and have a separate branch for each feature. When you switch to a branch, you can commit code changes which only affect that particular branch. Then, you can switch to another branch to work on a different feature, which won't be affected by the changes and commits made from the previous branch.

To create a new branch and change to it at the same time, you can use the -b flag:

git checkout -b <new-branch-name>

To list the branches for your project, use this command: git branch

To go back to the master branch, use this command:

git checkout master

5.3. Merging branches

You can merge branches in situations where you want to implement the code changes that you made in an individual branch to a different branch.

For example, after you fully implemented and tested a new feature in your code, you would want to merge those changes to the stable branch of your project (which is usually the default master branch).

To merge the changes from a different branch into your current branch, you can use this command:

git merge <branch-name>

You would replace <branch-name> with the branch that you want to integrate into your current branch.

5.4. Deleting a branch

To delete a branch, you can run the git branch command with the -d flag:

git branch -d <branch-name>

Integrating Git into a project that already exists

Follow these procedures in order to add git to an existing project:

1. Make sure you're in the project directory in your terminal.

2. Run git init to start git.

3. Make a .gitignore file that lists the files and directories that should be ignored (if this is not necessary, you can skip to step 4)

4. Use git add to stage your files. Make a commit with a suitable commit message, such as: git commit -m "first commit"

1. Working with remotes

Let's make a GitHub remote repository. When you're logged in and on the site, look to the top left for a button labelled "New" (see figure below).

• When you click the ‘New' button, GitHub will take you to a new page where you will be asked to give the repository a name. You may also give your repository a description, although this is optional.

• You may make your repositories public or private on GitHub.

• Anyone may access a public repository. Anyone with access to the source can see it and clone it to their own system for usage. Only individuals you choose have access to a private repository. It can't be seen by anybody else.

We may leave the choices to begin with a README and.gitignore unchecked because our project already has a README and.gitignore file.

2. Pushing code to GitHub

We need to add the files from our local repository to the distant one on GitHub now that we've built the repository. To do so, we must first link our local project to the remote repository.

To assist with this, Git includes the remote command. Git uses the git remote command to keep track of distant repositories and link local repositories to them. Let's assume we wish to sync our remote repository with our local one. The format of the command command is as follows:

git remote add <remote_name> <remote_url>

Therefore, the command we will run will be:

git remote add origin <url_to_remote_repository>

Note: Instead of constantly needing to mention the exact URL, the name origin is simply a more human-readable method to link to the remote repository. origin is only a common name; nevertheless, we may use any other name.

We'll want to push or upload our local code and its revision history to the remote repository once we've added the remote repository URL to our local one. This may be accomplished with the help of git push.

The git push command will push all of the changes made in the local repository to the remote repository.

Let’s make use of this command in our project. First, commit the .gitignore file we created earlier.

git add .

git commit -m "add .gitignore"

Now you can run the following command to push your code to the remote repository:

git push origin master

That's all there is to it. Your code has been successfully posted to a remote repository.

3. Updating the local repository

You must use the git pull command to update your local repository from a remote one. This program downloads all changes to the remote branch and merges them into your local repository.

Before a merging can take place, every change made to your local repository must be committed.

Congratulations on establishing your first Git repository, both locally and remotely! Many teams use Git and GitHub in their product development workflows, so you'll need to know how to use both. There's a lot more to learn.

6. Further learning

To learn more about Git, make sure to check the following resources:

• Git official documentation: https://git-scm.com/doc
• The free Pro Git book: https://git-scm.com/book/en/v2
• Learn about GitHub: https://guides.github.com/
• Video Reference : https://youtu.be/apGV9Kg7ics
• Git/GitHub cheat sheet: https://github.com/kunal-kushwaha/DSA-Bootcamp-Java/blob/main/lectures/1-git/git-cheat-sheet-education.pdf