Using Git and Github

First things first: Git and Github are two different types of software. Let us straight jump down into defining what they are, and the base characteristics on how they work!

Version Control

Git is an open-source, version control tool, created in 2005. It is also known as source control. Version control is a system that tracks and records changes made to a file over time. It is the brain behind remote work and controls computer source-code. It allows a team of developers to deploy and manage their source code, from wherever they are in the world.
The advantages of version control are the advantages of git.

• It creates a distributed system for code management.
• It creates snapshots of the current state of computer code.
• It allows a team of developers to work together efficiently and smartly.
• It creates branches, which keep multiple streams of work from different developers, independent of each other. These branches can be merged to form one file of code.
• Changes made to code are traceable to who changed it, the time it was changed, and previous versions.
• It is an operating system and language independent, thus can be applied to any programming language. Any developer can work on git from any system and with any language.

Git isn’t the only version control out there. Other version control systems include CVS, Bazaar, and SNV - the latter can be regarded as niche players or outdated based on the capabilities of Git.

Github

Github is often seen as being synonymous with Git. This is far from the truth. Github is a cloud-based hosting service that makes tools that integrate with Git. Github helps developers manage their repositories.
While git is installed locally on a computer system, Github is cloud-based. Git uses a series of commands while Github has a friendly GUI and user management system.

How do Git and Github connect?

Git manages the source code, which is then moved to a git repo while Github serves as a location for uploading copies of a git repo.
It is very possible to work with git without Github, but not possible to work with Github without Git.

Concepts of Git and Github

Repository

Repository, shortened as “repo” or “repos” is a very common term in Git and Github. A repo is a collection of files and folders associated with a project along with the file versions, history, and contributors. Github is like a storage location for repos.
Repos can be created and updated in Git and pushed to Github using the push command. On Github, repos are created on the web interface and files uploaded to it. Each repo has its own repo name. Operations like pull requests and forking can be performed on Github repos while cloning is performed on Git repos.

Git Branches

Branches are created to allow developers to work on a feature or a part of the software and change the code without upsetting the entire project. With git branch command, a developer can create, rename, edit, and delete branches.
A master branch is the default or main branch of a repo. Every other branch gets merged to the master branch for production or deployment. The master is technically the working version of the project.
To get a branch merged to the master, the featured branch must not have any conflict with the master.

Merge and Rebase

Merge and rebase commands are used to integrate changes from one branch to another. Their difference is in how this is achieved.
Merge uses the command

$ git checkout feature git merge master

Or a shorter line

$ git merge feature master

When a developer uses merge, the featured branch is merged to the master along with commits and the history of the branch files.

Rebase uses the command

$ git checkout feature git rebase master

Rebase integrates a branch into a master in a single patch. Unlike merge, it removes the commits history of the featured branch and rewrites its entire history. Rebasing transfers only the completed work from the featured branch to the branch, eliminating unwanted history.
Although both, merge and rebase have the same core functionality - to integrate branches, they are also different. Merging preserves the branch history, rebase does not.
Merging is best for public and shared branches where many developers are working on a branch. Rebasing is best for a cleaner, linear commit history. It causes issues with other branches if used on a public branch, this is because when a branch is rebased, the branch’s history diverges from everyone else’s. This divergence creates problems.

Pull Requests

A pull request is a function specific to Github. Pull requests provide a simple way to contribute to a project.
When a developer initiates a pull request, he is requesting that another developer (the software maintainer) pulls a branch from your repo to theirs.
Pull requests aren’t just used by developers on a team. In open-source software where the code is publicly available for modification and changes, contributors from the world send in their changes with a pull request.
After initiating a pull request, you’ll be prompted to compare your changes between the branches and the master. Initiating a pull request also means collaborating with the other developers to review proposed changes before your commit is merged.
A pull request has three statuses,

Open: This is a pull request that has not been attended to, is pending, or needs changes.

Closed: A refused pull request.

Merged: A pull request that has been merged to the original code.

Fork and Clone

Forking is done on Github while git clone is done on Git using the git clone command.
Git clone is a command that downloads the code in a remote repository to a local machine, usually the developer’s computer. A cloned repository takes the URL of the original repo and the repo name.

ssh://git@github.com/<username>/<repository-name>.git

Using git clone is like using the copy feature on a Microsoft Word documents. It gives you the exact copy of the content of the repo, as at the time the clone was initiated. Changes made to a cloned repo on a machine can be pushed directly to the original repo using upstream commands.

Forking a repo is creating a replica of a repo on another account to your personal account. Forking takes the content, commits, branches, and releases of the original repo to yours along with it.
There is a bridge between the forked repo and the original repo and this allows a developer to work on a code as if it were his own without affecting the original code.
Forking is widely used in open-source when a developer needs to contribute to a code. It works alongside pull requests to make contributions. 

To identify a forked repo, the URL and name of the forked repo are linked back to the original repo.

Commands in Git

git init

This command initializes a new local git repository. The repo name is added immediately after the command.

$ git init <repo name>

git commit

This command saves snapshots of a project’s working version. It does this by committing all the files to the repository. You can use commit only after staging the files using git add. Commits are usually added with a commit message.

$ git commit -m "Commit message goes here"

git add

This stages a file and gets them ready to be committed to the repository. You can stage in three ways.

• git add * adds all the files, folders and sub-folders in a directory, excluding files that begin with a dot like .gitignore.
• git add <filename> adds only the file that was specified with the filename.
• git add . adds all the files, folders and sub-folders in a directory including files that begin with a dot like .gitignore.

$ git add *

git config

This command allows you to tell git who you are. You can add your name and email.

$ git config --global user.name "Your name" 
$ git config --global user.email "Youremail@email.com"

git status

This command shows the status of a branch. Using this command tells us if there are untracked, staged, or unstaged files. It lets us know if there are files to commit, push or pull and whether a branch is up-to-date.

$ git status 

git checkout

This command is used for switching from one branch to another. We can also use it for checking out commits and files. There are two rules to using git checkout.

1. A branch must exist in the local version
2. Changes in the current branch must be staged or committed before checkout

$ git checkout <name-of-branch> 

git pull

This command fetches and downloads content from a remote repo and updates the local repo with the content that was downloaded.

$ git pull <remote repo> 

git push

This command pushes committed changes from a local branch to a remote repository.

$ git push [variable name] [branch]  

git clone

This command allows us to download source code from a remote repository to a local machine. It creates a copy of that repo in the local machine.

$ git clone <url-of-remote-repositiory> 

git merge

This command merge changes from two branches, usually a feature branch to a master.

$ git merge <branch name> 

git branch

This command creates a branch that allows developers to work together simultaneously on a project without touching the main branch until they are cleared to merge./p>

$ git branch <branch name> 

git revert

This command is a safe method for undoing changes made to a branch. Git revert is considered safer than using git reset. To undo a specific action or commit, we will use the hash code or commit id next to the commit we would like to undo.

$ git revert <commit id> 

Why is Github important for Git and developers?

Github has many collaborative tools that make it easier to work with git. Using git alone could be frustrating. It has no interface, just commands. Github provides that interface together with other tools developers may require.
Github allows developers to give certain rights to a repo, for example permitting certain users to push freely to a repo.
Github also has an ‘issues’ feature on repos that allow the team to keep track of bugs within the code. The ease with which developers can fork and contribute to a repo cannot be overemphasized.
Github provides its own socials that allow profiles to follow each other or to watch repositories.
Lastly, Github holds a developer’s resume. If you want to know how active a developer is, what they’ve been up to and the projects they have worked on, their Github page is the place to check.