{"id":17382,"date":"2017-11-15T13:30:49","date_gmt":"2017-11-15T13:30:49","guid":{"rendered":"https:\/\/www.heartinternet.uk\/blog\/?p=17382"},"modified":"2017-11-15T13:30:49","modified_gmt":"2017-11-15T13:30:49","slug":"mastering-git","status":"publish","type":"post","link":"https:\/\/www.heartinternet.uk\/blog\/mastering-git\/","title":{"rendered":"Mastering Git"},"content":{"rendered":"

Writing code and managing a good workflow is a challenge. Things can easily get messy, and bugs can appear from seemingly nowhere. This is where Git comes in. No matter who you are, or how much code you write on a daily basis, using Git will change your workflow and coding behaviour for the better and make collaboration in teams possible.<\/p>\n

Do you have problems such as obscure file names (eg final, final2, final3)? Do you struggle to tell what’s changed between versions of designs, files or code? Do you ever make changes to a file and then struggle to return to a previous point in the workflow? Version control can help you solve all of these problems.<\/p>\n

Git is a version control system. It allows for every change in your projects to get tracked, every line of code added or removed. So when you work on the new feature\/redesign-navigation<\/em> and make it worse, you can roll back to a point when it was working \u2014 or easily hand it off to someone who knows how to fix the problem. It can even be used for image files, you don’t necessarily get a pretty overview of what’s changed on most Git platforms, but you’re still able to commit changes to your designs.<\/p>\n

Git takes snapshots of your work that live in a project called a repository, also known as a repo. The snapshots make up a history of every change you save. You make these snapshots by committing changes. The commit is the most important part of Git, as it’s the way to save changed or new files to the history. Each commit you make gets a message, and it’s important to always write a message so you know what’s changed. The committing mindset is powerful, because it lets you think about your code (or design) in a modular way, helping you to organise your work in a pragmatic manner.<\/p>\n

You might have heard of something called GitHub<\/a>. GitHub isn’t Git, it’s just a platform for the Git repository. Normally you’d have to install Git on a server and then manage it, but tools were invented to prevent you from having to do this. GitHub is one of them, others are BitBucket<\/a> and GitLab<\/a>.<\/p>\n

Getting started<\/h3>\n

The best way to learn about Git is to do it yourself, so start by creating a GitHub account<\/a>. Then create a new repository, you can name it whatever you like.<\/p>\n

\"Creating<\/p>\n

You might have seen someone use Git from the terminal or command line. This is quite easy to do, but for our example, let’s use a UI \u2014 the GitHub Desktop App<\/a> for Windows and macOS.<\/p>\n

You now need to clone the repository you just created. Go to \u2018File > Clone Repository\u2026\u2019 and select your repository. You’ll be asked to select a folder, this is where the project will be stored on your computer.<\/p>\n

\"Cloning<\/p>\n

You can now save some changes to your repo. Add any file, and you’ll see the changes in the GitHub App.<\/p>\n

\"Adding<\/p>\n

So now we’ll add a message, and commit it. The best practice for commit messages is to use present participle tense \u2014 or like you\u2019d read in a cookbook:. \u201cAdd 250g of flour\u201d (or \u201cadd styling for about page\u201d).<\/p>\n

\"Adding<\/p>\n

When you’re ready to share your code, it’s important to push your changes using the \u2018publish\u2019 button, so other people can see them (and so your code is backed up somewhere). And then to get other people’s changes, you should pull their changes by using the \u2018fetch origin\u2019 button.<\/p>\n

You’ll now have a snapshot of your code history saved, and you’ll be able to see this in the history tab of the GitHub app. Your repo is now also shareable. If you go to your GitHub profile, you’ll be able to see the repository and the file(s) you just added.<\/p>\n

\"Your<\/p>\n

Congratulations! You’re now able to use Git to improve your workflow. That wasn’t so hard, was it?<\/p>\n

Better collaboration<\/h3>\n

When you\u2019re collaborating with a friend or a colleague on a project, things can get messy if you don\u2019t keep things organised. If you use the project, and then someone else pushes, you won\u2019t be able to push your changes until you\u2019ve pulled and \u2018rebased\u2019 or \u2018merged\u2019 the changes. This isn\u2019t the ideal way to use Git.<\/p>\n

Git works in a tree like structure. The main element of the project is the \u2018master\u2019 or the trunk of a tree. You can create a branch of the tree, work on a specific feature or bug fix on that branch, and then merge it back into master. Let\u2019s try this now.<\/p>\n

To create a new branch, go to the branch menu item, between repository and window. Click \u2018new branch\u2019 and name it along the lines of what you\u2019re about to do. If it\u2019s a feature, prefix it with feature\/<\/code>. If it\u2019s a bug fix, prefix it with fix\/<\/code>.<\/p>\n

\"Creating<\/p>\n

As before, create a new file with some text and commit and publish your changes.<\/p>\n

If you now look at your project in Finder \/ Windows Viewer, you\u2019ll see your two files.<\/p>\n

\"The<\/p>\n

Going back to the GitHub app, click the tab that says \u2018current branch\u2019 and then your branch name, and then select \u2018master\u2019. This is called a \u2018checkout\u2019.<\/p>\n

If you look at your file viewer again, you won\u2019t see the new file you just added to the feature\/add-new-file<\/code> branch. This is how branches help to solve issues with collaboration and file management.<\/p>\n

When you\u2019ve finished your work, you\u2019re going to want to have them in the master of the project. We need to do this in the GitHub web interface.<\/p>\n

Open your project at github.com, and then click the branches tab.<\/p>\n

\"The<\/p>\n

Next to your new branch, there\u2019s a \u2018new pull request\u2019 button. Let\u2019s click this. This new view includes all the information you need to see the changes you made between your new branch and master. You can add a pull request message, and set an assignee to approve the pull request which is a good idea if you\u2019re working on a project with other people. When you\u2019ve filled in all the information you feel is necessary for people to properly review your pull request, click the \u2018create pull request\u2019 button.<\/p>\n

You\u2019ll be taken to a new view, and have the option to merge the pull request. Let\u2019s do this. You should now also delete the branch.<\/p>\n

\"A<\/p>\n

If you go back into the GitHub app, change your branch to master and then fetch origin. You\u2019ll see the merge request in the history tab.<\/p>\n

Issue tracking<\/h3>\n

Git platforms come with some great tools for tracking issues, bugs, and feature requests. In the GitHub web interface, go to the issues tab, and click the button that says \u2018new issue\u2019.<\/p>\n

If you ever use someone else\u2019s GitHub repository and find a bug or need help, this is where you should go to report it so that someone can fix it \u2014 but check that someone else hasn\u2019t already submitted one for the same issue!<\/p>\n

We\u2019re now going to create a new issue.<\/p>\n

\"Creating<\/p>\n

Fairly basic, something that we could fix ourselves. It\u2019s good practice to check for an issue or submit a ticket yourself first to ensure that you don\u2019t work on something whilst someone else is doing the same.<\/p>\n

Because we plan on fixing the issue, you should assign it to yourself.<\/p>\n

\"Assigning<\/p>\n

Let\u2019s go fix that issue, and create a commit message for it. Whilst creating the commit message, we can reference the issue. The issue is given a number, in this case it\u2019s #2. To reference it, we use the same syntax.<\/p>\n

\"Creating<\/p>\n

Using the keyword \u201cfixes\u201d automatically closes the issue on GitHub.<\/p>\n

More advanced features<\/h3>\n

.gitignore<\/h4>\n

When working with Git, you might see ghost files appear such as .DS_Store<\/code> or Thumbs.db<\/code>. You can make Git permanently ignore these sorts of files by adding a .gitignore file to your project. I recommend using .gitignore.io<\/a> to generate a file for you based on your criteria. In the input field, add Git, Windows, macOS, and Linux.<\/p>\n

Depending on which tools you\u2019re using, search for them too. If you use Photoshop, add Adobe to your list. If you use the npm package manager, add Node.<\/p>\n

When you create the file, you\u2019ll see it in plain text in your browser. You then need to copy all the text, and copy it into a file called .gitignore<\/code> inside of your project. The .<\/code> is very important in getting Git to read the file as a settings file.<\/p>\n

Releases<\/h4>\n

When you\u2019re happy with your project, you can create a release. This is a lesser used feature, but quite a nice one to use on larger projects or client projects. Go to the releases tab in the GitHub web interface. Then click \u2018create a new release\u2019.<\/p>\n

\"Creating<\/p>\n

In this section, I\u2019d recommend using the tagging suggestions that GitHub gives you on the right side of the input fields.<\/p>\n

In the text area that asks you to describe your release, you should note down your major changes. In a future release of this project, I might be able to list changes and fixes. Think of it similarly to an update to an app you have on your phone.<\/p>\n

Forks<\/h4>\n

GitHub is filled with millions of public repositories. It also has some great ways of searching for new ones such as Explore<\/a>. You might find a project that would work well for your team, but needs a little bit of tweaking. You can change someone\u2019s code without annoying them, you just need to fork their code.<\/p>\n

Open a repository, and then along the very top there are three primary action buttons.<\/p>\n

\u2018Watch\u2019 allows you to get notifications to your email about changes. \u2018Star\u2019 allows you to show your support of a project. It\u2019s similar to the \u2018Like\u2019 button on Facebook or the heart on Twitter. And finally, there\u2019s the \u2018fork\u2019 button. If you click it, you\u2019ll be taken to a new view that will look quite similar to the previous one. However, if you look across the top of the page, you\u2019ll see that the project\u2019s name is now proceeded by your username and there will be some text that says \u201cforked from username\/project\u201d.<\/p>\n

You\u2019re now able to clone this project to your machine and work from it locally and make as many changes as you like.<\/p>\n

You may even end up adding a new cool feature or fixing a bug. Then you have the ability to create a pull request to the original project and contribute to the open source ecosystem. You\u2019re also now able to use Git in a work environment, you know the basics and that\u2019s all you need to know to get started and to get your colleagues involved too. One of the great things about Git is that you can make it fit to your needs and requirements. There aren\u2019t really too many right or wrongs.<\/p>\n

Resources<\/h3>\n

In this article we used the tools GitHub<\/a> and the GitHub Desktop app<\/a>. Here are some other great tools:<\/p>\n

UIs<\/h4>\n