Note: This post is part 1 of two-parts Learning to Work with Git & GitHub post series. This learning post is still in active development and updated regularly.
For self-taught web developers, learning Git is not an easy subject to tackle, especially if not-working in team. Web developers who work alone, all on-their-own and may not feel a need to learn Git & use GitHub. Because the software is so huge, there is lot to learn, even before getting started to use it. For most beginners, learning to use Git & GitHub could come with time consuming steep learning curve. My recent interest on ReactJs and GatsbyJs, learning & getting started using Git has become essential.
The main objective of this learning series is to understand the very basic of Git, its commonly used most basic commands, and getting started using Git, by creating a local project and lunch it to GitHub server.
Part 1: Introduction to Git – The Basics (this post)
Part 2: A Collection of Basic Git Commands – A Cheat Sheet
The objective this part 1 of the series is to get familiar with Git and its key features, common Git terms, basic Git commands, and Git workflow from a perspective a front-end web developer.
What is Git & How it Works?
Git vs GitHub
Git is a distributed version control system (VCS) for tracking code changes in coding (software development) projects. It is the most preferred method of co-ordinating projects among team members. GitHub is a open-source development platform to host code repositories to review code & manage projects.
Git is the most widely used open source distributed version control system (VCS) in software development and used by more than 70% developers worldwide. In nutshell, Git sits on the top of file system and allows to manipulate files without changing the master file. It stores references of every changes in files as snapshot of that moment.
Git documentation outlines following key features of Git:
- Git is a snapshots of a file mini system. When a file is changed, Git takes snapshot of that file and stores only reference to that snapshot.
- Most Git operations are local and it does not need extra server resources.
- Git has integrity. Git uses unique ID, called SHA-1 hash (a 40-character string), to store everything and not by filename.
- Git generally only adds data. All the actions taken in Git only add data to Git database.
- Git has the three states (see below). The three main Git states that files can reside are: committed, modified, and staged.
A brief explanation of the three git states:
- Git directory: It’s where Git metadata and object database of a project are stored. This what gets copied while cloning a repo from remote Git server.
- Working directory: It’s a single checkout of one version of project. These files are pulled out of Git directory and placed in disk for use or modification.
- Staging area: Its is simple file stored in Git directory which contains information that goes into the next commit. It is also referred as “index”.
Additional Information: Git Basics | Git Documentation
Git & GitHub Terminology
Before getting started with the Git & GitHub, it is important to get familiar with some commonly used terms. Some selected glossary terms from the GitHub glossary:
- Git : an open source, distributed version-control system (VCS) for tracking changes in text files, and core GitHub technology.
- GitHub : a platform for hosting and collaborating on Git repositories.
- Repository : A repository is the most basic element of GitHub. They’re easiest to imagine as a project’s folder.
- Private repository : Private repositories are repositories that can only be viewed or contributed to by their creator and collaborators the creator specified.
- Add : This command is used to add file to Git repository.
- Branch : A branch is a parallel version of a repository. It is contained within the repository, but does not affect the primary or
masterbranch which allows to work freely without disrupting the “live” version.
- Clone : A clone is a copy of a repository that lives on local computer instead of GitHub server, or the act of making that copy.
- Commit : A commit, or “revision”, is an individual change to a file (or set of files). It’s similar to saving a file, except with Git, every time a file is saved it creates a unique ID (eg “SHA”) that allows to keep record of what changes were made when and by who.
- Fork : A fork is a personal copy of another user’s repository that lives on local account.
- Fetch: Fetching refers to getting the latest changes from remote repo without merging them in to compare with local branches.
- Index : This refers to cache where changes are temporarily stored before they are committed.
- Merge : Merging takes the changes from one branch (in the same repo or from a fork), and applies them into another. Often happens in a pull request.
- Push: sending committed changes from local repo to the GitHub remote server.
- Pull: Pull refers to when you are fetching in changes and merging them. If someone has edited the remote file you’re both working on, you’ll want to pull in those changes to your local copy so that it’s up to date.
- Hash : It refers to a unique file ID created by Git. For example, if two files have identical contents then they will have the same hash value where as if the two files with different contents contain different hash values.
- HEAD: It’s a commit hash value and referring to a pointer to the most recent commit on the current branch.
- Status: A status is a type of status check on GitHub.
- Diff : Its a command to that is used to determine what changes have been made.
- Log : This refers to the revision history of a file or folder.
- Remote : a common repository on GitHub. It can be connected to local clones so that changes can be synced.
- Upstream : This refers to where file changes are pushed, typically the master branch.
For full lists of terms: GitHub Glossary
Some Basic Git Commands
Before using Git, it is essential to familiarize with most basic commands to create file, copy, change and combine codes in projects. Git Handbook lists the following basic git commands with brief explanation:
git init: Create an empty Git repository or reinitialize an existing one. It adds a hidden sub-folder within the existing directory that houses the internal data structure required for version control.
git clone: Clone a local copy of a repository that already exists in the remote. The clone includes all the project’s files, history, and branches.
git add: Add file contents to the index. The “index” holds a snapshot of the content of the working tree, and it is this snapshot that is taken as the contents of the next commit. Thus after making any changes to the working tree, and before running the commit command, you must use the
addcommand to add any new or modified files to the index. (eg. track files).
git commit: Record changes to the repository. This command saves the snapshot to the project history and completes the change-tracking process. (eg. commit tracked files).
git status: Show the working tree status. This command shows the status of changes as un-tracked, modified, or staged.
git branch: List, create, or delete branches. This command shows the branches being worked on locally.
git merge: Join two or more development histories together. This command is typically used to combine changes made on two distinct branches.
git pull: Fetch from and integrate with another repository or a local branch. Incorporates changes from a remote repository into the current branch. (eg. file download).
git push: Updates remote refs using local refs, while sending objects necessary to complete the given refs. (eg. upload files).
Additional information : Git Reference
What is The GitHub Work Flow ?
GitHub work flow is the process where new development or pull request can be tested safely without making change to the master repository through branching. A Git flow can be simple or very complex depending upon the projects and team members involved etc.
As per Git documentation, a basic Git workflow consists of the following three steps:
- Perform file modification in the working directory.
- Stage the modified file, adding their snapshots in the staging area.
- Make a commit, which takes the files from the staging area and stores that snapshot permanently to the Git directory.
An example of more complex branch-based work flow, from the GitHub Training, has following six steps:
- Create a branch: Branch are usually created from master, which allows to team members to contribute in parallel efforts. Name branch descriptively.
- Add commits: This is snapshot of development efforts within a branch to create safe, revertible points in the history. Make commit to the branch locally & regularly.
- Open a pull request: It publicize project . For feedback or help
- Discuss & review code: Team members participate to in the project by code review, testing & commenting open pull requests.
- Merge: This is the process where changes from one branch (eg. repo or fork) and applies them to the other.
- Deploy: Once the project is merged & pushed to the master, it is deployed.
Some GitHub Tips
Some common tips while working on GitHub include:
- Commit often: Make commit as small & commit as often as possible.
- Test, then commit: Never commit incomplete work.
- Use commit messages: Include descriptive commit message about the change made.
- Branch out: Create new branches as required.
- Settle on Common Workflow: Use a common workflow among team members.
In this Git basics learning-note post, defining Git and its key feature, common Git terms, basic Git commands, and Git workflow were discussed. In the 2nd part of this learning-note series, basic Git commands will be created as a cheat sheet and a few working examples will be discussed.
While preparing this post, I have referred the following references extensively. Please refer to original posts for more detailed information.