Build your first Git repository

While it is true that Git is selected as a version control tool by many important software, it does not only work with these important software, it can also manage your shopping list (if they are important to you, of course!), your profile, weekly or diary, project progress log, or even source code!

It is necessary to use Git, after all, you must have been crazy about a backup file that was not able to identify the publication of this information.

Git can't help you unless you start using it, and now is the best time to start learning and using it. Or, in Git's words, "no other push can be as helpful as Origin HEAD". I promise you will understand that soon.

analogy to recording

We often use the term "snapshot" to refer to the image on a computer, because many people can feel the photo album filled with different times. This is useful, but I think Git is more like a recording.

Maybe you're not familiar with the traditional studio card recorder, which consists of several parts: a rotating or reversing hinge, a tape that holds the sound waveform, a sound waveform recorded on the tape through the pickup head, or the sound waveform on the tape is detected and played back to the audience.

In addition to playing the tape forward, you can also rewind the tape back to the previous section, or skip over the back part.

Imagine the band recording tapes in the 70 's. You can imagine them practicing songs over and over, until all the parts are perfect and then recorded on the track. At first, you'll record the drums, then the bass, then the guitar, and finally the lead singer. Every time you record a recording, the studio staff will rewind the tape and enter the loop mode so that it will play back the part you recorded earlier. For example, if you're recording bass, you'll hear drums in the background music, like you're drumming yourself, and then the guitarist will hear drums, bass (and cow ringtones) and so on when recording. In each loop, you will record a portion, and in the next loop, the worker will press the record button to merge it into the tape.

You can also copy or replace the entire tape if you want to remix your work.

Now I hope that the description of the recording work in the 70 's is vivid enough so that we can think of Git as a recording job.

Create a new Git repository

First, we need to buy some tapes for our virtual recorders. In Git's words, these tapes are warehouses, which are the basis for all the work done, meaning that this is where git files are stored (i.e. git workspaces).

Any directory can be a Git repository, but let's start with a new directory. This requires the following three commands:

Create a directory (if you like, you can do it in your graphical file manager). )
Switch to the directory in the terminal.
Initialize it to a Git-managed directory.

That is, run the following code:

$ mkdir ~/jupiter  # Create directory $ cd ~/jupiter     # Enter directory $ git init.       # Initialize your new Git workspace

In this example, the folder Jupiter is an empty but legitimate Git repository.

With the warehouse, the next thing is going to be done. You can clone the repository, you can go back and forth at a historical point (provided you have a historical point), create alternating timelines, and do anything else that Git can do.

Working in a Git repository is the same as working in any directory, and you can create new files, copy files, and save files in the repository. You can do all kinds of things as usual. Git is not complicated, unless you want to complicate it.

In a local Git repository, a file can have the following three statuses:

File not tracked untracked: You created a new file in the repository, but you didn't add the file to Git management.
Tracked files tracked: Files that have been added to Git administration.
Staging Area file staged: Modified tracked file and added to Git's commit queue.

Any files that you add to the Git repository are not tracked. These files are saved on your computer's hard drive, but you didn't tell Git that it was a need to manage the files, using our tape recorder analogy, the tape recorder is not open, the band began to busy in the studio, but the tape recorder is not ready to record.

Don't worry, Git will tell you when it happens:

$ Echo ' Hello World ' > foo$ git statuson branch masteruntracked files: (use "Git add <file> would be committed)    Foonothing added but untracked files present (use "Git add" to track)

You see, Git will remind you how to add files to the commit task.

do not use git commands for git operations

Creating a warehouse on GitHub or GitLab requires only a few mouse clicks. It's not hard, you can click on the "New Repository" button and follow the prompts.

It is a good practice to include a "README" file in your warehouse so that people can see what your warehouse is doing when they browse your warehouse, and what is more useful is to let you know what it is before cloning a warehouse with something.

Cloning a warehouse is usually simple, but getting repository churn permissions on GitHub is a little more complicated, and to verify with GitHub you must have an SSH key. If you use a Linux system, you can generate it with the following command:

$ ssh-keygen

Then copy the contents of your new key, which is a plain text file, you can open it with a text editor, or you can view it using the following cat commands:

$ cat ~/.ssh/id_rsa.pub

Now paste your key into the GitHub SSH configuration file, or the GitLab configuration file.

If you clone your project by using SSH mode, you can write the changes back to your repository.

Also, if you don't have Git installed on your system, you can use GitHub's file upload interface to add files.

Trace File

As the output of the command git status tells you, if you want Git to keep track of a file, you have to use the command git add to add it to the commit task. This command staging area the file, which is stored in a file waiting to be submitted, or it can be used in a snapshot. Git add commands are different when you include files in a snapshot, and when you add new or temporary files that you want to manage with git, but at least for now, you don't have to worry about the difference between them.

Analogy recorder, this action is like opening the recorder to start recording. You can imagine pressing the pause button on a tape recorder that is already in the recording, or going back to the beginning and waiting to record the next track.

When you add a file to Git management, it identifies it as a tracked file:

$ git add foo$ git statuson branch masterchanges to being committed: (use "git reset HEAD <file> ..." to unstage) new file :   foo

Adding files to the submission task is not "preparing for recording". This is just the state of putting the file in preparation for recording. After you add a file, you can still modify the file, it is just marked as tracked and in staging area, so you can pull it out or modify it before it is written to "tape" (You can, of course, add it again to make some changes). But please note: You have not recorded the file on tape, so if you break a previously good file, you will not be able to recover, because you do not write in the "tape" that the file is still a good moment.

If you finally decide not to log the file to the Git history list, you can undo the commit task, which is done in git:

$ git reset HEAD foo

This is actually the release of the recorder to prepare the recording state, you just in the recording studio relay a lap.

Large Submissions

Sometimes you want to submit some content to the warehouse; we use a tape recorder analogy, which is like pressing the recording key and recording it on tape.

In the different stages of a project, you will press this "record key" countless times. For example, if you try a new Python toolkit and eventually implement the window rendering function, then you are sure to commit it so that you can fall back to this stage when experimenting with new display options. But if you draw some graphic grass in the Inkscape, you may need to wait until you have some content to develop before submitting. Although you may have submitted it many times, Git doesn't waste a lot of time and doesn't take up too much disk space, so the more I submit, the better it seems to me.

The commit command "logs" all the staging area files in the repository. git only "records" tracked files, that is, at some point in the past you use the git add command to add all the files to the staging area, as well as files that have been changed since the last commit. If there has been no commit before, then all the tracked files are included in this commit, in Git's view, this is a very important modification, because they have never been placed in the warehouse into a place.

Completing a commit requires running the following command:

$ git commit-m ' My great project, first commit. '

This saves all the submitted files, which can then be used for other operations (or, in the English TV series "Dr. Mystic", the Time Lords speak of the Gallifreyan language, they become "fixed points of Time"). This is not just a commit event, but also a reference pointer to the commit that you found in the Git log:

$ git log--oneline
55DF4C2 My Great project, first commit.

If you want to browse more information, you only need to use the git log command without the--oneline option.

In this example, the reference number when submitting is 55df4c2. It is called "commit hash Commit hashes" (LCTT: This is a hash code generated by the SHA-1 algorithm that represents a git commit object), which represents all the new changes that you have just included in your submission, overwriting the previous record. If you want to "rewind" to your commit history point, you can use this hash as a basis.

You can think of this hash as a SMPTE timecode on a sound tape, or a bit more, which is like the gap between two different songs on a vinyl record, or a track number on a CD.

When you change the files and add them to the commit task, and finally complete the commit, this generates a new commit hash, each of which represents a different version of your product.

That's why musicians like Charlie Brown use Git as a version control system.

In the next article, we'll discuss all aspects of Git HEAD, and we'll really reveal to you the secrets of time travel. Don't worry, you just have to read on (maybe you're already reading it).

Build your first Git repository