Source: GitHub Blog | Author: Alyson La
생산성, 효율성 등을 개선하기위한 GitHubbers의 팁을 특징으로하는 일련의 게시물 중 네번째입니다.
GitHub에서 일을 시작했을 때, 나는 처음에 회계사로 고용되었고 2012년에 입사하기 전에 코드조차 본 적이 없었습니다. 세금 양식을 작성했어야 하는데 GitHub이 하는 일을 묘사하도록 요구하는 나는 “소셜 리포지토리”라고 썼습니다. 😄
It’s thanks to the social nature of GitHub as a product (and many helpful co-workers) that I started reading other people’s code and pull requests while learning Git and GitHub basics. After two years of honing my coding skills by attempting to automate some accounting processes, all the while facepalming due to yet another merge conflict, and working on open source side projects, I was offered a position to become one of GitHub’s first Data Scientists. Now as a member of our Data Science team, I get to apply my analytical and coding skills together to help GitHub (the business) better understand our users.
But even working at GitHub, learning Git and GitHub was hard! As its own form of an open source contribution, I want to share my top tips for getting started using GitHub for the folks who are new to coding.
Tip 1: GUI vs CLI—why not both?
When you first get started with Git/GitHub, you might get to a fork in the road (no pun intended) and will need to pick whether you use the command line interface (CLI) for git commands or a GUI (Graphical User Interface) like GitHub Desktop—or even the GitHub extension for Visual Studio. My advice is to try both! Try out cloning repositories, branching, and committing changes to a branch—first in the CLI, then using a GUI. Which do you prefer? I ended up sticking with using Git commands in the terminal because I wanted to become more proficient in bash commands anyway. I also typically clone repositories using GitHub Desktop since it’s just a click away.
Try both and choose the tool that works best for you right now—it may be a combo of both. As a new coder, you’ll likely want to build some muscle memory with git and bash commands in the terminal, but you may also enjoy the ease of use of a GUI for some tasks—like cloning or comparing diffs. Also, ask your fellow coders what tool they use and why! When learning Git/GitHub, it can be easier to use the same tooling as your colleagues or classmates who can help you get unstuck when you run into an inevitable git situation.
Tip 2: Set up your dotfiles
This is a game-changer for folks running git commands in the terminal. I didn’t learn about dotfiles until after I’d been coding and using Git/GitHub for multiple years. I’m still bummed that I didn’t know about this sooner!
Dotfiles have many uses but one neat use is they allow you to customize your terminal prompt so you can see what git branch you are on and if you have uncommitted changes. YAY! I forked my dotfiles from a former co-worker (John Nunemaker) but if you search GitHub for
dotfiles you’ll find loads of options.
Tip 3: Make a GitHub Pages site
A GitHub page is a personal or project-based website that GitHub hosts for free! It always helps to have an actual project to push to GitHub so you can practice your Git and GitHub skills.
The screenshot pictured above is my simple personal website hosted on GitHub Pages, which I forked from another co-worker, @cobyism. For more GitHub Pages inspiration, check out the source code for all the websites in this GitHub collection or browse repositories tagged #github-pages. For fellow data scientists out there, there’s also a neat project called fastpages, which allows you to easily publish a GitHub Pages site directly from a Jupyter notebook using GitHub Actions.
Tip 4: Review the GitHub Flow
So you have a GitHub account, you’ve installed Git and/or a Git client, you’ve got a sticky note for some common Git commands on your monitor, and perhaps you’ve updated your dotfiles and created a personal GitHub pages site. But how does one actually use GitHub to collaborate? The GitHub Flow graphic (pictured above) is from a kid’s learning site, and after seeing it for the first time, I finally understood what GitHub is good for! By sharing our code, others can benefit from it and we can make something better, together! From the previous tips, note how both my dotfiles and personal website were forked from other people!
Tip 5: Practice merge conflicts
Merge conflicts can happen when you want to merge your pull request into a master branch but there are competing commits, and Git needs your help to decide which changes to incorporate in the final merge. This often happens when people make different changes to the same line of the same file, or when one person edits a file and another person deletes the same file.
I can’t remember the number of times that I’ve abandoned a project or pull request because I hit a merge conflict. They scared me, the docs on how to fix them scared me, and then I was in VIM and wanted to quit forever.
Then I realized I needed to face my fear, so I started a practice repository, created a merge conflict on purpose, and walked through the documentation, and watched a video on how to fix merge conflicts. I did that a few times. And now you can fix simple merge conflicts in the GitHub User Interface, so that’s been handy.
Today, when I hit a merge conflict, I’m slightly less scared and calmly make my way deleting the carrots, knowing that thanks to version control, I can’t mess things up too much. Or worse case, you can just delete the project and re-clone.
Tip 6: Your first open source contribution can be Docs and that’s OK!
If you’ve made it this far, the next step is to connect with the open source community. Follow some people, star or watch some repositories, and when you’re up for it, make a contribution back to open source software by opening a pull request to request incorporating your changes back to the project. My first open source contribution (many, many moons ago) was a guide on how to use GitHub for RailGirls. Your first OS contribution can be docs and that’s OK! In fact, each year the GitHub Data Science team publishes the State of Octoverse report that details the most popular and trending repositories and, for the past several years, some of the most widely contributed-to projects have been docs-related—for example, Azure Docs and Azure DevOps.
I’m sneaking in one last, maybe obvious tip which is…take a Git and GitHub class or tutorial! Here are a few that are worth checking out:
I hope this list of tips was helpful and if these or any other tips have been useful to you on your journey to learn Git and GitHub, we’d love to hear about it!
Do you have a GitHub Protip?
Do you have a tip, trick, or hack that makes your daily life easier on GitHub? Share it with us on social media with #GitHubProtips.