GitHub Hands-On Part 1: For Individual Developers

This article is a translated version of my original post on Qiita. Original (Japanese): https://qiita.com/segur/items/601277fbbe8cfa08678b

GitHub Hands-On Part 1: For Individual Developers

I hosted a GitHub workshop for Unity creators at my company! Here's the material, made available for everyone to use.

This is a series, so feel free to read the parts that interest you!

GitHub Hands-On Series

Target Audience

This guide is for:

Occasionally, you'll see references to Unity, as our company uses GitHub to manage Unity project history. However, not knowing Unity won’t be a problem as the procedures here are straightforward.

Creating a GitHub Account

If you already have a GitHub account, skip this step.

For those without one, please create an account on GitHub.

Detailed instructions can be found here:

https://reffect.co.jp/html/create_github_account_first_time

The Free plan is sufficient.

Installing Fork on Your PC

Download and install Fork from https://git-fork.com/.

This is a GUI application for managing Git on your PC.

Why Git?

Why should you use Git?

To Safely Manage Edit History!

One of the primary reasons is the safe management of file edit history.

For example, managing history by duplicating files:

Let's avoid managing history via file or folder names as it easily becomes confusing!

Instead, use dedicated software to manage edit histories!

Easily Revert Changes!

Much like saving and loading in a game, reverting to a previous state makes tackling complex tasks more manageable!

Edit Safely with Multiple People!

When both Person A and Person B edit simultaneously, each edit history is recorded separately, so neither's work is wasted!

You can safely integrate work while resolving conflicts by comparing them!

Aspiring to make editing a safe, hassle-free process!

Git is No. 1 in Share

While there are other tools available, Git holds the largest share!

Creating a Personal Repository

What is a Repository?

A repository is the environment where edit histories are managed.

In English, repository means a storage place.

graph LR
    subgraph GitHub
        repository[Repository]
    end

Creating a Repository on GitHub

Click on + > New repository in the top right of GitHub.

image1.png

Naming the Repository

Enter a name for your repository.

For Unity projects, PascalCase is commonly used (although this may vary by industry).

Enter GitPractice for this exercise.

image20.png

Choose the Visibility

Select Private.

If you select Public, it will be exposed to the world!

For handling internal company information, always select Private.

image32.png

Click the Create Button

Click the Create Repository button!

If you see a page like the following, you've succeeded!

image13.png

The string displayed in the text box (underlined in red) is the repository URL—make a note of it.

There are two types: HTTPS and SSH. We'll use SSH.

Cloning

What is Cloning?

Cloning is copying the server's repository to create one on your PC.

Names for clarity:

graph LR
    subgraph GitHub
        remote[Remote Repository]
    end
    subgraph PC
        local[Local Repository]
    end
    remote -->|clone| local

Cloning with Fork

Click File > Clone at the top left.

image45.png

Enter the repository URL you noted earlier in the Repository Url field.

image19.png

Parent Folder designates the directory on your PC for this work; select any folder you like. Ensure it doesn’t contain Japanese characters or spaces for safety.

Leave Name as its default (same as the repository).

Then press Clone.

SSH Connection Setup

Skip this step if cloning was successful.

If cloning failed, click here for help.
You might encounter an SSH error if this is your first time cloning. Let's resolve that! This is the first hurdle! Configuration is needed only once per PC, not every time you clone. This step uses the command line—apologies for that! On Mac, open Terminal. On Windows, open Command Prompt. Run the following:
ssh -T git@github.com
If you don't see **You've successfully authenticated** in the response, your SSH setup isn't completed. Follow the guide below to create a public/private key pair and register the public key on GitHub. [https://qiita.com/shizuma/items/2b2f873a0034839e47ce](https://qiita.com/shizuma/items/2b2f873a0034839e47ce) Run this command again:
ssh -T git@github.com
If **You've successfully authenticated** appears, your SSH connection is set up. Try cloning again with Fork. It should work this time!
If not, click here for more help.
If the SSH connection was successful but cloning failed, Fork's settings might be off. Click **File > Configure SSH Keys** and confirm no files other than `id_rsa` are registered. ![image35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221845/03aeaa6a-7d5d-5aae-51d9-8cd070aa30cb.png) ![image44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221845/a5377086-e11d-7bb4-21ac-5c1093c0720c.png)

Committing

What is a Commit?

A commit denotes a unit of data logged in the edit history.

The action of logging into the edit history is also termed committing.

Create a README.md

Select Open in > Open In File Explorer in the top right of Fork to access your working folder.

image41.png

Create a file named README.md. .md indicates it's a Markdown file.

image24.png

Open README.md in a text editor, input the following, and save it.

# GitHub Hands-On

Save in UTF-8 encoding or it'll appear garbled in Fork.

Add README.md to Stage

In Fork, click Local Changes and note that README.md appears under Unstaged.

Clicking README.md shows changes on the right.

If garbled, save README.md again using UTF-8 encoding.

image9.png

Click Stage to move README.md from Unstaged to Staged.

Commit README.md

In the lower right, enter Added README in the Commit Message field and click Commit File.

Click Branches > main on the left to see the Added README entry.

image39.png

Edit README.md

Open README.md again in the text editor, update its content as follows, and save.

# GitHub Hands-On
This is a file for GitHub Hands-On.

In Fork, check Local Changes to find README.md under Unstaged.

The differences from the previous commit are shown on the right.

If not displayed in a two-column view, click the icon at the top right.

image43.png

Commit README.md Again

Like before, click Stage, then enter the commit message Updated README, and commit.

Now, click on All Commits on the left.

Verify that an Updated README entry has been added.

image10.png

This illustrates how edit histories are managed in commit units!

What is Staging?

Staging is where file change data that is candidate for commits is stored.

graph LR
    subgraph Working Directory
        workingDirectory[README.md]
    end
    subgraph Local Repository
        subgraph Stage
            stage[README.md]
        end
        subgraph main branch
            main[README.md]
        end
    end

    workingDirectory -->|add| stage
    stage -->|commit| main

The main branch appeared suddenly, which will be explained next time!

Pushing

What is Pushing?

Pushing is copying the contents of the local repository to the remote repository.

graph LR
    subgraph PC
        subgraph Local Repository
            local[main branch]
        end
    end
    subgraph GitHub
        subgraph Remote Repository
            remote[main branch]
        end
    end

    local -->|push| remote

Push

In Fork, press the top-left Push button.

image16.png

A dialog like this will appear!

image11.png

Press Push to start the push!

Check the GitHub Page

After pushing, reload your GitHub repository page.

If the contents of README.md are displayed like below, you've succeeded!

image12.png

Conclusion

That's all for this session—well done!

Next session covers collaborative development! We hope you will continue to practice along!

https://qiita.com/segur/items/a3f7b9063829850391c5

This article was created referencing the following articles. Thank you for them!