Git Good: Getting to Know and Use GitHub Better
“If you look at the top 100 sites, you’ve got a handful of social sites, thirty flavors of Google with national footprints, a lot of media outlets — and GitHub.”
— Brian Doll, VP Strategy @ GitHub, 2015
GitHub is easily one of the most popular websites on the planet, a collection of all the professional aspirations and open-source dreams of software coders everywhere. Its genius lies in having taken code and creating the equivalent of a bustling market for people anywhere to create, collaborate, and browse literally billions of lines of code — on- or offline.
This model, made possible by allowing repositories (collections of data, repos for short) to be locally cloned, allows a high degree of freedom for coders building out software. But, as a newly minted software engineering student at the Flatiron School unfamiliar with all of this, its importance and reputation were completely lost on me.
Instead, tasked with my very first pairing project, my teammate and I grappled with using GitHub more than we actually coded our project at first. And when multiple cohort mates approached us asking questions about the service, I realized there must be so many other us out there like us: newbies in the game needing a quick primer on the labyrinth that is GitHub.
With that, let’s start with a little background.
A Very Brief History of GitHub
Git, the version control tracking software and the backbone of GitHub itself, was created by Linus Torvalds in 2005. (Before that, he developed Linux — you might’ve heard of it.)
In February of 2008, the company formerly known as Logical Awesome LLC was founded and — fun fact! — was created using Ruby on Rails. One year later, GitHub hosted 46,000 repos. By 2013, that number was up to 10 million.
Impressively, just five years later, Satya Nadella’s Microsoft bit, acquiring GitHub for a cool $7.5 billion — not bad for what was essentially a plucky startup out of San Fran.
Cool, But What’s The Big Deal?
While development teams and companies can opt to use an internal version tracking system or a GitHub “competitor” like BitBucket, the vast majority of other options pale in comparison to the industry titan. GitHub is just that good, folks, making it the quasi-standard for dev teams globally.
GitHub’s benefits include:
- As that quasi-standard, companies can more confidently hire junior developers knowing they’ll usually have been exposed to the Git workflow.
- Hobbyists and professionals can easily collaborate with open-source and professional communities all in one place. In software development, collaboration makes the world turn.
- Developers can access full local repos with a complete history of changes on their own computers without any network access necessary.
- GitHub complements an agile workflow with its dynamic tools.
- GitHub is a marketer’s best friend, letting them execute frequent, more aggressive marketing for every bug fix, feature adjustment, and addition in the pipeline separately versus in one big update that can take much longer to put together.
- Speaking of bugs, GitHub allows devs to respond to bug reports quickly and effectively.
- GitHub sports compatibility with a wide range of systems and protocols essential to software development and the internet at large.
- Large projects are light work for GitHub.
In short, GitHub is all that and a bag of chips. But how the heck do we use it?
A Far Too Short Overview of the Git Workflow
While there are many GitHub workflows available for your consideration, I’ll be dipping our collective toes into what’s known as the Centralized Workflow. This workflow will be most common in smallerwhich begins by forking (or creating a path from) the repo you want to contribute to. That’s called the Master branch. (Never forget: the Master Branch is sacred.)
To facilitate our many additions and edits, we have a few handy tools available to us: Branches, Commits, and Pull Requests.
- Branches are safe environments in which you can try out your own ideas that do not affect the Master branch until someone in charge reviews and accepts changes. It’s good practice to keep the name of your branch descriptive for others (e.g. refactor-authentication). In your terminal, use git branch to check which branch you’re on and git checkout <name of branch> to switch.
- Whenever you add, edit, or delete a file during your programming, you’re making changes. When satisfied, you can git add . that code to stage it to the queue, preparing it to be latter finalized on your branch when you git commit. It’s good practice to add messages to every commit to communicate exactly what’s being done. The command git commit -m “<insert message here>” allows you commit it to the branch with a message. If a conflict arises, use git pull — rebase origin master to incorporate upstream changes first before placing your commits on top of them.
- The moment of truth for all coders is the Pull Request. Initiate one with git request-pull [version] <start> <url> <end> or by heading straight to GitHub. When you do, it initiates a review of your commits by collaborators regarding technical and aesthetic matters relating to your code. Pull Requests allow all this to happen while you apply feedback and push edits to your branch in real-time.
Should you get your pull request approved, you’ll get the green light to deploy from your branch for final testing before merging with the Master branch. Once merged, Pull Requests are saved so there’s a historical record for everyone to reference. (GitHub really likes keeping tabs on things.)
Some Best Practices for GitHub
We’re in for a quite a journey in the world of code. As we grow and expand our programming capacities, let’s keep some best practices when using GitHub front of mind:
- Make clean, single-purpose commits and make them often. It’s easier on teammates looking at changes and it makes for simpler rollbacks.
- Write meaningful commit messages that concisely describe what changes are being made. Your team will love you for it.
- One more time: Commit early, commit often.
- Don’t alter published history. The Master branch should always be a single source of truth for anyone looking at it, ever.
- Use pull requests whenever possible. Direct commits to master are acceptable for trivial changes.
- Try using separate branches for each enhancement and/or fix.
- Like commits — and pretty much anything involving titling — title branches appropriately. (Base titles according to the issue being fixed, for example.)
- DO NOT merge new commits from Master to your branches. Either rebase to master or wait until the final merge.
