This guide will help you to create a professional looking GitHub profile intended to use it as a portfolio of your work.
You’ll also learn how to impress recruiters by contributing to open source projects.
If you don’t have experience with Git in Github you can learn about version control on Git.
Just follow the link and go on Freecodecamp and watch the tutorial.
Then come back here when you’re done and we’ll work on your profile.
Artists use a portfolio to hold examples of their work. Similarly, the GitHub profile is a portfolio of the programmers work.
Use GitHub in the same way — to show off your work to potential employers.
Your profile will also show how you work.
Don’t worry! We’ll go through various ways to make your GitHub profile into a professional portfolio.
P.S.: Do you have an amazing GitHub profile? You should apply here
Let’s look to an eggselent GitHub profile through the eyes of a recruiter.
This is Scott Moss’ profile. He’s a software engineer at Angular Class.
Over on the left is the personal information.
A picture with a friendly smile can help recruiters make a connection with you but it isn’t mandatory.
If you’re not using a picture of yourself be sure to include a picture that somehow captures your personality. But nothing crude. Like Scott did.
Below is some general information and a link to his email and twitter profile.
Recruiters can look through Scott’s tweets to get a sense of the things he’s interested in.
The descriptions are nice so that we know what these repositories are for.
He has an impressive list of contributions to repositories. This is a clear indication that he is involved in collaborating with others on open source software.
Employers can look through Scott’s contributions to judge how well he works on a team.
This is one of the first things a hiring manager is going to look at.
Each square is a day. The darkness of the green indicates how many contributions were made on that day.
You can see that Scott is very active, making at least one contribution most days.
It’s pretty clear he spends a lot of time working with code.
A good sign to a recruiter.
The heat map with the activity gives a really good sense if people are passionate about coding.
It doesn’t have to be all the time but here it is:
People who love to code have steady patterns that correlates with the success in the workplace
A well written ReadMe is one of the most important parts of a good repository.
The reading is necessary for others because it tells people:
This is an important skill. You should learn how to write documentation for humans.
Commit messages are essential for communicating why your code was changed. This is for your coworkers or collaborators, and also for your future self. Let’s go through some best practices for writing commit messages.
Here is a message format you can use:
The first line is the subject. This should be a short description of what changed.
Nothing like “fixed it” or “did something,” these need to be clear and informative, and try to avoid profanity.
The subject should be 50 characters or less, with the first letter capitalised, and end without a period.
You should also include a short annotation about the type of the commit, if it is a bug fix, a feature, change to the documentation, etc.
The body is next, this is where you give a more detailed description of why you made the change.
The body should typically have around 72 characters per line. This is to ensure that the message fits into a terminal window when using git on the command line.
You’ll also need to make sure there is a blank line between the subject line and the body. You can also add bullet points, using asterisks or dashes, when you need to make a list.
Some commits don’t require a body in the message. If you fix a typo for example, it’s okay to only have a subject line.
You can also include a footer, typically this will be used to indicate which issues or bugs the commit addresses.
A more fleshed out example looks like this:
feat: Summarise changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
If you use an issue tracker, put references to them at the bottom,
See also: #456, #789
This does come with an exception of course.
If you are working on an open source project, be sure to follow the message format for that project. This will make the maintainers happy and increase the chance your pull request is accepted.
As a programmer, you’re often going to be working with others on a shared code.
So employers want to see that you can collaborate.
By contributing to open source projects, you can demonstrate how well you work with others.
It also shows that you’re helpful and love working with code.
Apply these best GitHub practices moving forward and attract the attention of recruiters and senior software engineers.
You’ll want to:
A personal side-project may grow into something bigger. You can’t always predict what will catch the eye of a recruiter or senior software engineer, but when it does, you want to showcase your best work.
Once you’ve implemented the necessary changes to make your profile more professional, remember to maintain activity by regularly making commits on GitHub.
Good luck & Happy Coding!
Tutorial source: Udacity