Git and Github: A Beginner’s Guide for Complete NewbiesShivam Ranjan RajBlockedUnblockFollowFollowingMay 1Despite what television and movies tell us, life as a software developer does not include sitting in a dark room, our keyboard illuminated only by the glow of the monitor, the thought of interacting with another human being repulsive.
No, life as a software developer is social and collaborative–sometimes to the point of frustration.
That’s why we have git and Github.
Git is version-control software that makes collaboration with teammates super simple…once you’ve gotten past the initial learning curve.
It can be intimidating, but that’s why I’m here!What is Git?Well, it’s not just the way we Southerners shoo varmints off our porches, I’ll tell you that.
Like I said above, Git is version-control software.
It was created by Linus Torvalds, the guy who invented Linux.
You don’t have to be running Linux to use git–you can use it on Windows and Mac, too.
Git lets you easily keep track of every revision you and your team make during the development of your software.
You all share one repository of code that is worked on independently and then merged back together.
You also do not need to be connected all the time because the project is both saved locally on each machine and remotely (probably at Github).
Git is special (and pretty much mandatory) because you can to revert back to any previous version of your code, branch off and develop a specific feature without affecting anything or anyone else, and maintain safety from data corruption because of its distributed nature.
It also provides easily implemented encryption and cross OS compatibility, as well as asynchronous, non-linear workflows so that no matter where you are, you can work on some aspect of your project.
Basically, if you’re not using git, you’re coding with one hand tied behind your back.
Required VocabularyWhen you’re first starting to use git, it can be intimidating.
Commands and concepts may seem totally foreign if you’ve never used any form of version control in the past.
You will pick them up super fast, though.
Repository:Often referred to as a repo.
A repository is the collection of files and folders that you’re using git to track.
The repository consists of the entire history of your team’s changes to the project.
It’s the big ole box you and your team throw your code into.
Github:The most popular remote storage solution for git repos.
It also allows you to set access permissions for projects, track and submit bugs, accept feature requests, subscribe to repository notifications, and utilize a graphic interface, rather than use the command line.
Repos default to public, but paid accounts can have private ones.
Commit:Think of this as saving your work.
When you commit to a repository, it’s like you’re gathering up the files as they exist at that moment and putting them in a time capsule.
The commit will only exist on your local machine until it is pushed to a remote repository.
Push:Pushing is the bread to committing’s butter.
Committing throws your files into the timecapsule, and pushing is what launches the capsule into space.
Pushing is essentially syncing your commits to the cloud (again, probably Github).
You can push multiple commits at once, too.
You can work offline, commit lots of work, and then push it all up to Github when you’re back in civilization with that sweet, sweet wifi.
Branch:You can think of your git repo as a tree.
The trunk of the tree, the software that goes live, is called the Master Branch.
That’s the one that goes live.
The branches of that tree are, well, called branches.
These are separate instances of the code that offshoots from the main codebase.
You might branch off for a single feature or an experimental patch.
By branching, you can preserve the integrity of the software and have a way to revert if you do something totally bonkers.
It also allows you to work on your task without stumbling into your team’s way (or they into yours).
Merge:When a branch is polished up, free of bugs (as far as you can tell, at least), and ready to become part of the primary codebase, it will get merged into the master branch.
Merging is just what it sounds like: integrating two branches together.
Any new or updated code will become an official part of the codebase.
Anyone who branches off from the point of merging will have this code in their branch as well.
Clone:Cloning a repo is pretty much exactly what it sounds like.
It takes the entire online repository and makes an exact copy of it on your local machine.
You will need to do this for any number of reasons, not the least of which are starting in the middle of a project with a new team, swapping workstations, or starting over from a corrupted repo.
Please do let me know your thoughts, questions or suggestions in the comment section below.
You can also send your feedback at shivam.
ranjanraj.
srr@gmail.
comFork:Forking is a lot like cloning, only instead of making a duplicate of an existing repo on your local machine, you get an entirely new repo of that code under your own name.
This feature is mainly used for taking an existing codebase and going an entirely new direction with it, which happens a lot in open-source software; developers see a base idea that works, but want to go a different way with it.
Forking allows that to happen.
You can also play in another developer’s repository like it’s your own personal sandbox.
And if you do something that you think they may like, you can make a pull request for it to be merged in.
Pull Request:A pull request is when you submit a request for the changes you have made (either on a branch or a fork) to be pulled (or merged) into the Master Branch of the repository.
This is the big time.
This is where the magic happens.
If the pull request is approved, you will have officially contributed to the software, and Github will forever show exactly what you did.
However, if the pull request is denied for any reason, the denier will be able to give feedback on why the request was turned down and what you can do to get it accepted.
Getting Started and Required CommandsThat wasn’t too bad, was it?Right.
Now that you’ve got a clear idea of what git is, it’s time to dig in and get your hands dirty.
I should take this opportunity to note, however, that I am going to assume you’re using the command line to interact with git.
Sure there are graphical git clients (and Github even allows you to do pretty much everything through it’s web interface), but for the purposes of this post we’re not going to bother with them.
You will do a handful of things outside of the terminal, but the command line is going to be your new BFF.
So that’s what we’re going with, too later in next blog.
Please feel free to write your thoughts,questions or feedback to me at shivam.
ranjanraj.
srr@gmail.
com.