What is Git?
Many of you have probably heard of GitHub before you ever heard of Git.
When looking for a program or a piece of software to use as a reference, you often land on a GitHub page, and I suspect many of you have simply downloaded something without really understanding how the site works.
GitHub is indeed a place where programs are shared, but it is more than just a sharing site: it is a tool for using a tool called Git online.
Git is a tool for version control of files.
By modifying files and recording those changes, you can return to any recorded version at any time.
When you ask someone to review a presentation draft, you probably save the file before the review, the reviewed file, and the file you revised based on the comments as separate files.
With a tool like Git, you can handle those changes easily, and all within a single file.
The three areas in Git
A record made with Git, and the act of making that record, is called a “commit”.
The place where commits accumulate is called a “repository”.
In other words, a repository is the place that holds the change history.
A repository on your own computer is called a “local repository”, while one hosted remotely, such as on GitHub, is called a “remote repository”.
When you want to manage files with Git, you specify the folder that Git will manage.
Within that folder there are three areas:
the working tree, the staging area, and the Git directory.
The working tree is where your files live, and simply editing a file here does not yet save the change history as a commit.
The staging area is where you register the files to be committed.
Files on the stage likewise have not had their change history saved yet; think of it as the place where you declare, “I am going to commit this file.”
The Git directory is where commits are stored.
Files committed here are stored as files that will never be altered.
In principle, the content recorded by a commit cannot be changed or deleted afterward.
Once something is committed to the Git directory, it has been recorded as part of the change history.
Basic use of Git
I will leave the detailed usage for you to look up, but here I give a rough overview of the actual operations.
Git is generally operated using Git Bash on Windows (installed together with Git) and the terminal on macOS and Linux. (Here I will refer to both simply as the terminal.)
There are GUI tools that may feel more familiar, but once you get used to it, using Git from the CUI is extremely convenient, so I recommend starting with the CUI from the beginning.
You should get the hang of it within an hour.
First, to start managing files with Git, create a local repository.
Begin by moving to the directory you want Git to manage in the terminal.
Then,
git initEntering this gets you ready to use Git for version control.
Next, to record changes in the staging area,
git add ファイルパスもしくはディレクトリパスRunning this registers the specified file in the working tree to the staging area.
Next,
git commitThis commits the files in the working tree.
To check which file is currently in which state,
git statusrun this.
The commit history can be
git logchecked by running this.
Basically, the workflow is to run git add, then git commit to create a change record, and to use git status to check the current state whenever you run into trouble.
Below is a reference.
It is a book that is very easy to follow even for beginners, and I referred to it while writing this article.
If you want to study this in more depth, I recommend it.
