Is anyone able to summarise for me what the heck exactly is Github (its main purpose, how it/does it affect me as a designer)?
This is a question that Harrison, an experience designer at Portable, surprised the rest of us with on Slack last month. It led to some head scratching and back and forth discussion among us developers. Here's what we ended up telling him. Does it help, Harrison?
In case you were wondering, git doesn’t stand for anything. The inventor just thought the British slang word 'git', meaning an ignorant or annoying person, was a funny word.
In a nutshell, git is a program that lets us track and manage changes and history in files – generally code. It’s used for version control.
Github is an online service that hosts git. It gives a user interface for version control, collaboration, tracking and comparing changes throughout the history of a project. It also offers related services, such as allowing people to raise an issue if there is a bug in a project’s code, hosting websites and keeping a log of errors that happen on live apps and websites. Bitbucket is another version of the same thing.
The basic pattern of developing software using the git workflow
It can be helpful to have a basic understanding of the workflow and terms, even if you aren’t doing these things yourself. The basic pattern of developing software using the git workflow is something like:
1. Pull down the project code from Github or Bitbucket. This is like downloading a folder of files from Google Drive.
2. Create a branch to track the changes. This is creating a duplication of the folder of files and giving it a new name describing what the changes will be, for example ‘homepage-banner’. It's like a branch in an evolutionary tree. One ancestor can have multiple branches each with small or large mutations.
3. Edit and mess about with the code in various files.
4. Commit the changes. This is saving a record of your changes in the historical timeline of changes for the project. It is usually a brief descriptive sentence about what has changed.
5. Push the branch back up to Github. This is basically like uploading your duplicate ‘homepage-banner’ folder back to Google Drive.
6. Create a pull request to merge the branch back into the main code. A pull request is a method of submitting contributions to a project. A developer asks for their changes to be considered for inclusion in the project's main folder (we call this the master repository).
7. Other developers review the changes in the pull request and approve it. This is where quality control happens, helping developers to write code that is easy to understand and prevent bugs from sneaking in.
8. It gets merged. After merging, the changes from the branch (in our example ‘homepage-banner’) are saved into the main folder.
This diagram might help.
How design works at Portable
Generally, this process doesn’t concern the designers. Some companies or teams have design assets in Github. In this case, knowing how to check out the project, update it and merge it is good to know about.
At Portable, our designers usually work in Figma, which has its own way of handling versioning. When new design assets or design assets have been updated, they let our developers know, who then update the project with the new assets.
We’re also working on some tools to automate the handover between design and code. Our designers have developed a UI Toolkit, and we are using the Figma API to build ways to automatically pull out design assets and styling information for our projects. If you're interested in learning more about this ongoing project, check out the recording of our webinar ‘Design smarter, not harder: digital product design without starting from scratch.’
What can using Github do for designers?
Imagine we’re working on a project together and I, the developer, have just finished building a key component of your designs. I make a pull request and Bitbucket builds a Storybook (a tool that allows a visual preview of individual components). When the Storybook has compiled, you receive a Slack message or email to let you know it’s ready for viewing. You go to the pull request in Bitbucket and click on the link to the Storybook page.
Storybook is an open source tool for building user interface components and pages in isolation. It streamlines user interface development, testing, and documentation as individual components and pages can be viewed and reviewed without the entire website existing (and all the infrastructure needed to support it).
After reviewing some new components, you need to request additional changes. So, you jump to the pull request in Bitbucket and leave a comment there for me to see. I make the changes and you check back on the Storybook to review them.
Once you are happy with how things are looking, you can approve the pull request in Bitbucket. In this case, it is handy to know how the pull request process works so you can participate in it by adding comments and approving it.
Sometimes, there is an additional layer to this process. The link to the Storybook for the pull request can be accessed in a separate service. One such service, Chromatic, is a tool that works with Storybook to automate the gathering of feedback, visual testing, and documentation. You, a designer, can log into Chromatic and browse multiple projects and their Storybooks at once, and leave comments in Chromatic on specific components.
Once the pull request has been merged, you receive a Slack message or email alert that the staging website has been updated. Now you can see how the new components look on the staging site and let me know if something needs to be changed.
For developers, it’s kind of like magic
For the technology team at Portable, git forms a major part of our everyday toolkit. It is super handy because it is like an infinite ‘undo’ button. We can make changes more fearlessly while giving ourselves little breadcrumbs to find our way back. It tells a story about a project, with a full history of the changes made from inception to the current state, with all of the developer’s thoughts about their decisions along the way.
We love that it's super simple to get your head around the basics, but that you can (google how to) do a lot of crazy harder stuff. For example, you can cherry-pick changes from other branches and combine them into a new one.
Using Bitbucket and Github, pull requests let us agree on each other's changes before they become part of the official main branch – so it’s not only a version control but a feedback and quality control tool, too. You can set up rules so that, unless your pull request has been approved by another developer, you can’t merge your changes. This helps prevent bugs from sneaking into our websites and apps.
Finally, it's one of the few pieces of tech that has (almost) universal adoption. We all use different languages, frameworks and operating systems: I use PHP, Andy uses Typescript and Cam uses Go. I run Windows, Andy runs Mac and Cam runs Linux. But we all use git.
Sign up to our email newsletter to get updates about our events, work and research
