This article has participated in the third “topic writing” track of the Denver Creators Training Camp. For details, check out: Digg Project | Creators Training Camp third is ongoing, “write” to make a personal impact.

preface

Sure you want to write “easy-to-read introduction to Git”, to study b site search related video, found a video that is probably the most easy to understand: have you seen the Git tutorial | what is Git? How does it achieve code versioning? How does it relate to Github? This article is based on the video tutorial, combined with the knowledge I have learned, of course, also added some content, such as Git related commands.

What is code versioning?

For example, in the video, the designer has experienced this kind of revision experience. After the final draft, he will make many revisions and adjustments.

In order to prevent the boss or party A sentence, or use the version of it.

Designers will keep a copy of the previous version of the design document every time they overhaul the design draft, so the behavior of keeping a copy of the previous design draft is actually carrying out version management of the design draft.

But this is pure artificial management, very simple and rough, not convenient to maintain.

In fact, when we were in college, when we were writing papers, we would also encounter this situation. We would first write the first draft, and if we need to revise it, we would copy it and revise it on the new document.

Git is a tool used to help us manage code version when we write code. It is powerful and efficient. Most of the Internet companies use Git for code version management.

git

Git is a program, but also a software, but it is not the same as our graphical interface software, the way to open the terminal, input git related commands to operate, is a black window, of course, it also provides graphical Git tools for code management.

Don’t be afraid to use commands. When you use commands for a long time, you will find that using commands can be more efficient than using graphical interfaces.

Either way, let’s take a look at how Git helps with code versioning.

Instead of specific commands, the following will describe them in plain language. The commands involved in some operations will be explained in a unified manner.

When you use Git, you’re actually working on a folder, like I’m creating a new folder.

After you initialize it with git, the folder has a hidden.git folder.

This folder is designed to hold versioning information for all files in this folder.

A folder initialized by Git is commonly called a Git repository.

In this repository, you can use git commands to version code files and other files in the repository.

Very important concepts in Git: archive and branch.

File and read

This archive is a call that oneself sum up, resemble a bit before hit game of single machine computer, often need to undertake archive, want you to save file only, you can jump to a certain to save the game progress of file at any time.

Git has a similar function.

We can think of the above git initialized folder as a folder stand with a background where Git does the versioning of code files behind the scenes.

The background determines what version of the code file to display on the folder display table.

In the background, there is a master who is responsible for keeping records.

We’re going to let Git do some archiving for us, and this master archiving master is doing it for us.

We will create a new text file in the folder named “first time using git.txt”, and write version 1 in it. After saving the file, we can archive the operation.

The archiving operation, however, needs to be divided into two steps:

  1. You need to tell Git which files you want to save first, because sometimes you can change a lot of files, but only want to save a few, so the command to tell Git which files to save is necessary.
  2. Git has a staging area. When you want to save some modified files, you need to run the add command to add them to the staging area.

When you add the relevant files to the temporary storage area, and you ask the master administrator to make an archive for us, he will automatically record the changes in the temporary storage area to the archive, so that the master record bar will generate an archive record.

Next, we will modify the text file. I will create a new line in it and add the three words of version 2, and then ask the master to save a file for me. In this way, a new record will be added to the bottom record bar, and the contents of the current folder will be displayed as the contents of the latest record.

Continue to modify, I will write the third line version 3, and save it again, there is an extra record on the archive record bar, at the same time, the contents displayed in the folder are still the latest record content.

When you have more than one archive, you can use Git to switch back and forth between the archive files. This is also the operation of reading files. When I switch back to the first archive, you will find that the first git. TXT file displays “version 1”, which is the first archive.

When I switch to the second archive, the text of the document has another version two.

When you switch to a different archive, the files displayed in your folder will change to the state of the contents of the files recorded in that archive.

branch

Branching is also an important concept in Git.

When you initialize a folder, it automatically creates a branch named Master. Yes.

You can think of each branch as an archivist. All of your previous operations are in the master branch, which is responsible for recording and managing files for you. When you use Git, you are bound to be in a branch, just like when you started. Git will automatically assign you a file manager named Master.

When you create a new branch in the master branch, for example, called Fixbug, git calls a new file manager named Fixbug for you.

Git will give him a copy of the latest record from the master’s recordbar as the fixbug master, the initial record of the recordbar from which he started working.

It’s just that you can only call on one archivist at a time to help you with your work. To call which archivist you need to switch to the appropriate branch. Now I switch to the new branch Fixbug and change the name of the file to branch 2.

Then I’ll document it again

Then switch back to the Master branch and you’ll see that the file name changes back to its original name

I switched back to the fixbug branch and the file name changed to branch 2 again, so there are a few features about the branch:

  1. In the new branch, you can also archive and read the contents of a file. After all, fixbug and Master are two administrators, and they use their own file bars
  2. In Git, you can not only switch between different archives within branches, but also between branches. When you switch branches, the file information of the folder is the status of the last archive under the branch you switched to
  3. When you change the contents of a file on a branch, it doesn’t affect the contents of the previous branch or the rest of the branch, the contents of the branch are completely independent of each other. And branches can be created at will if you need them, which means you can have Git call up as many archivists as you want.

More importantly, branches can be merged.

For a simple example of git use, for example, when I develop my own personal website using Git, when I start to write code, I will put the initial files of my website into a folder, and then I will initialize it with Git, so THAT I will have a default master branch. I’ll put it in a file.

Then I created a New Develop branch, the Master branch, where I managed release-able versions of the code, and where I did most of my core development.

That I’ll be the first to switch to the develop branch, and then I started to develop my personal website, the basic layout of the development, I save a file, then I continue to develop my personal web site content, and then development is completed, I save a file, and then I continue to develop websites registered login function, after development, I save a file.

After that, I think I can launch my website for the time being. So WHAT I’m going to do is I’m going to merge the Develop branch onto the Master branch, go back to the Master branch, and merge the Develop branch, and then merge the Master branch, and then I’m going to have the code for the latest live website, And then I can use the code on the Master branch to distribute and get my website online.

The develop branch was merged, but the merge just copied the last record of the Develop branch to the last record of the Master branch. It didn’t delete the Develop branch, so when the site goes live, I can continue on the Develop branch. Then I developed other features of the site, such as a message board feature

Then save a file

At this time, I suddenly found a bug on my website, so I had to switch to the Master branch, and then create a branch of Bugfix in the Master branch, and then SWITCH to the Bugfix branch, and then do a crazy operation and modification, and then submit it. Do some filing.

Then switch back to the Master branch and merge the Bugfix branch to fix the bug. I can then redeploy the site with the new code under the Master branch.

And then I might have to merge some of the code that’s on master into the Develop branch so that I can get rid of any bugs that I have in the Develop branch.

After all, don’t forget the master branch, which was merged from Develop, so I can continue to develop the rest of my site on Develop and then merge it into the Master branch. Then use the code on the Master branch to deploy the site.

This is the simplest way to use branches. Real teams use branches more rigorously in code development.

If you’re an individual developer, you can use branches as you see fit,

Therefore, the use of branches allows each business code to remain independent, different code processing requirements, can be separated and synchronized, avoid mutual influence. Once done, it can be merged into the Master branch, which is dedicated to publishing code.

These features, shown in the screenshot above, are at the heart of git’s implementation of code versioning control.

We’ve taken a look at some of the most important concepts in Git, and hopefully this gives you a sense of how git helps you implement file and code versioning. Knowing this will help you learn how to use Git in detail.

Git command in plain language

Plain language The git command
Use Git to initialize the folder git init
Tell Git which files you want to archive and add them to the staging area git add <file>Example:git add test.txt
After adding it to the staging area, ask the master administrator to help us make an archive and generate an archive record git commit -m <message>Example:Git commit -m
When there are multiple archive records, switch between record files git reset --hard commit_idCommit_id is the corresponding archive record
Git has summoned a new archivist named Fixbug for you git checkout -b <name>orgit switch -c <name>Example:git checkout -b fixbug“Create + Switch Branches”
Switch to the new branch fixbug git checkout <name>orgit switch <name>Example:git checkout fixbug
Switch back to the Master branch and merge the Develop branch git checkout master

git merge develop
Develop new features in the Develop branch, find a bug on my site, switch to the Master branch, and create a new branch of Bugfix in the Master branch git checkout master

git checkout -b bugfix
After fixing the bug, switch back to the master branch and merge the Bugfix branch git checkout master

git merge bugfix

Common git commands

  1. git clone <[email protected]>:xxxx, Download repository
  2. git initTo initialize the local repository.git
  3. git status -sbTo display the status of all current files
  4. Git add Specifies the path to the git fileTo add changes to the staging area
  5. Git commit -mTo formally commit changes to the.git repository
  6. Git add XXX and git commit -m ‘XXX’. Add and commit. There you go. You’ve got Git.
  7. git logViewing Change History
  8. git pullRetrieves updates from a branch of the remote host and merges them with the specified branch of the local host
  9. View branches:git branch
  10. Create a branch:git branch <name>
  11. Switch branches:git checkout <name>orgit switch <name>
  12. Create + switch branch:git checkout -b <name>orgit switch -c <name>
  13. To merge a branch into the current branch:git merge <name>
  14. Delete branch:git branch -d <name>

reference

  • This is probably the most easy to understand: have you seen the git tutorial | what is git? How does it achieve code versioning? How does it relate to Github? Check out this tutorial: 100 Front-end Problems for Designers -05
  • That’s all you need to know
  • Easy to understand Git introduction
  • Easy to understand Git introduction

Wrote last

Through this article, I hope to help you understand how Git helps us to achieve file and code version management, and understand how Git works.

If there are any mistakes in this article, please correct them in the comments section. If this article helped you or you liked it, please like it and follow it.