Let’s Git Started….
Today, software is everywhere. It’s in everything we do. We interact with software almost every moment than ever, often without even knowing it. Almost every product nowadays contain software in some form. Established industries are also evolving to adapt to software and improve performance. Software touches every corner of life and that software can be built efficiently by working together.
That’s where GitHub comes into action.
By Definition, GitHub is a platform that helps people solve their problems together. You may have heard that GitHub is a code sharing and publishing service, or that it’s a social networking site for programmers or version control tool. All the statements are true, but none explain exactly why GitHub is special. Its like other version control systems, which manages and stores revisions of projects; although it’s mostly used for code, it could be used to manage any other type of file, such as Word documents, PSD, text etc. Think of it as a file system for every draft(version) of a document.
Before GitHub, development was a really tumultuous. Every change would end up with tens or hundreds of similar files, making it rather cumbersome to directly compare different versions and sharing those with teammates is another headache.
GitHub Version control enables you to keep track of work and to easily explore the changes made, be it data, scripts, notes, etc. in a much smoother and easier way. It also stores your files online as back up of your work and to be shared among team members.
“One who forked my heart, caused me to think that I was ready to commit.”
— Droidverine
So now we are going to cover few git basic terminologies with relevant commands below:
Git init :
It is used to create an empty Git repository or reinitialize an existing one.
Example with o/p:
Git add :
The git add command adds a change in the working directory to the staging area. It tells Git that you want to include updates to a particular file in the next commit.
Example with o/p:
Git rm :
The git remove command removes a change in the working directory from, the staging area. It tells Git that you want to exclude a particular updates for a commit.
Example with o/p:
Git commit
Record changes added in staging area to the local repository.
Get Shivraj Patil’s stories in your inbox
Join Medium for free to get updates from this writer.
Example with o/p:
Git pull :
The git pull command is used to fetch and download content from a remote repository and immediately update the local repository to match that content.
Example with o/p:
Git push :
The git push command is used to upload local repository content to a remote repository. Pushing is how you transfer commits from your local repository to a remote repository.
Example with o/p:
Git Clone :
Clones a repository into a new directory.
Example with o/p:
Git branch
A branch is used to save new changes in a working release, separately. These changes can later be implemented by “merging to master branch”
Example with o/p:
Git flow in a nutshell
The Three C’s Rule:
Rule #1 : Create a Git repository for every new project
Making a habit of using git is very important. Having a dedicated repository is the first step to being able to use version control for every line of code you write. Using version control is how you will work once you join a company and start working on real projects. make it a habit.
Rule #2: Create new branch for each new feature
Let’s say you are working on your college project with your team and your friend wants to build a new feature lets say “Profile” module/screen, so Creating a dedicated branch for this new feature, assign it a meaningful name (e.g. Profile_Branch), and commit all the code to that specific branch. Doing so allows you and your team members to work on different features in a parallel way while keeping the specific code for each feature separated from the master or rest of the branches. This avoids the unstable code to get merged into the master branch. Even if you are the only person on your team,you must get used to this feature (Branching) .
Rule #3: Call Pull Requests to merge code to Master.
Every repository starts with a master branch by default. Never push changes directly to the master branch, I repeat never !. Instead, you should use feature branches as described above, and open a new Pull Request to merge the feature branch code with the master branch code.
In a real life, someone will look at your Pull Request and do a code review before approving it. GitHub will even run automated tests to your code and let you know if there is an issue with it.
