A Dead Simple Intro to GitHub for the Non-Technical
An introduction to GitHub definitions, structure, and uses geared towards non-technical makers and business leaders.
GitHub is a key technology when it comes to software development, but getting started — or getting familiar — can often be intimidating for non-technical users.
A Github repository is the fundamental building block of Github. Normally, a repository corresponds to one application or piece of code that can perform certain functions on its own.
If you are coming from a traditional business setting you might be wondering, ‘why would anyone set their code to public. I mean it’s an intellectual property.’
Yes, that’s true.
Most companies don’t make their repos public. Especially if they are business-critical. But, if a company wants to make something open source, then public Github repos are the way to do that. Public repos also allow other developers to use existing code as scaffold for their new projects. In this way you help the developer community without opening up your wallet.
The ambition of GitHub is to create an open, collaborative environment where the world’s repositories (buckets of code) live, breathe and evolve over time.
Individual developers GitHub it to highlight their talent and build their reputation. Github has become so common for most developers that it’s more important than their CV. It provides hiring managers an easy way to judge the talent before getting to interview.
Crowdbotics enables non-technical business leaders and makers turn their ideas and specs into production-ready software. Learn more here, or start building now.
Git vs Github
Before we dive into what constitutes a typical Github repo, let’s make an important distinction first. Github is actually two things: Git and Hub.
Git is an open source version control software. It allows developers to work on any given project simultaneously by keeping track of changes. If something goes wrong, Git allows you reverse the changes easily. Another commonly used version control is SVN.
“Hub” is nothing in its own right but it represent the social network of developers built on top of Git. Github does not really own the Git software, but they have created a platform for people to more easily access and collaborate using Git.
The breakthrough feature of GitHub is that it made it super easy to share/show your code to the world. While giving you the option of controlling which parts you want others to see and which you would like to hide.You no longer have to worry about where to store your code if you are working on a personal fun or portfolio project. You just need a Github account.
Companies have Github accounts for the same reason. Github provides an easy way to store your code online with built-in version control.
For individual users, Github is free to use. Github makes money from companies who have multiple projects running and require features like private repos. At the end of the day, Github is a SaaS product much like any other you use.
You pay for it and,
* it stores your code
* allows you to work on the code in real time
* Git, the version control software, is built right in.
GitLab and Atlassian Bitbucket are two well-known competitors to Github.
You don’t have to be a developer to create a Github account. Anyone can create an account.
Your profile is of course dependent on your coding skills. Or does it?
You can actually use Github to store any document that can benefit from easy access, version control, and collaboration.
Github will treat the changes made to those documents the same way it does changes for code. It’s a super easy way to maintain version control on a document. Of course Github lacks the word processing capabilities of a sophisticated word processor. But, it’s still super helpful collaboration tool. For example, you can use it to maintain a list of products you are working on, which you can share as part of your PM portfolio.
Structure
The fundamental building block of Github is a repository or ‘repo’ for short.
One repo normally corresponds to one project. At least, that’s how it’s designed to work.
Take the example above: your project is that you need to have a snapshot of all projects you are currently working on. So, you create a repo to list all these various project. Even if it’s a simple text file that you need to store, you need to create a repo first. Inside each repo there are branches. These are like folders and subfolders on your desktop.
Every repo has a master branch. Master branch is what gets deployed to the server if your repo contains code. Unless a piece of code is part of master branch it won’t be live.
Developers can create their individual branches work on, say, a new feature. Once the feature is ready, they can merge their branch with the master. More often than not, developers perform these operations via Git commands (remember Git is a version control software Github is built upon). Most commonly used Git commands are:
Clone — Clone makes a copy of a repo. Copying a repo is desired in case someone else needs the code. But more often than not devs use it to make an offline, locally stored copy of the Github repo. Working directly on the remote copy is not desirable.
Commit — Once a developer has cloned the code on her local machine, she can start writing code. Again, new code should go in a new branch. Once done, she can commit the changes. Commit saves the changes to local repo.
Push — While commit saves the changes in the local, push transfers those changes from local to the remote stored at Github.
Pull Request — Pull Request or simply PR is at the heart of Github collaboration. Supposed you made changes to your new branch. Pushed it to remote Github repo so everyone else could see but no-one is aware of your work as yet. Everyone is busy in their own work. Pull Request is a way to ask other devs to review your code. A PR shows the differences between two branches in green (additions) and red (subtractions).
Merge — Once someone has reviewed and approved a developer’s changes, it’s time for merge. Merge command merges new code with the master branch.
That’s all you need to know to get stared with GitHub yourself or participate in dev-related discussions regarding your product.
It obviously helps if you know more.
As a next step, try out this ‘Hello World’, no coding required version of getting started with Github. You’ll learn how to,
- Create and use a repository
- Start and manage a new branch
- Make changes to a file and push them to GitHub as commits
- Open and merge a pull request
Thanks for reading.
Want to build software as a non-technical individual?
Crowdbotics enables non-technical business leaders and makers turn their ideas and specs into production-ready software. Learn more here, or start building now.
