Six main threads to learn about Git:
The workspace Git object
The staging area The tree object
The local library Commit object

Version control

Version control software is a system that records changes to the content of one or more documents for future reference of revisions to a particular version.

Function: You can retrace a file back to its previous state, or even the entire project back to a point in time. Even if the files in the entire project are changed and deleted, they can be restored to their original appearance. You can compare the details of changes in files, find out who made what changes last, find out what caused weird problems, who reported a defect when, and so on.

Centralized version control system — REPRESENTS: SVN

Advantage:

  • There is a single centrally managed server that holds revised versions of all files
  • People working together connect to the server via a client to pull out the latest files or submit updates
  • Everyone can see to some extent what others in the project are doing, right
  • Administrators can also easily control the rights of each developer and manage a centralized version control system
  • Each time you save the difference you need a little bit less disk space but you can roll back very slowly

Disadvantages:

  • A single point of failure on a central server
  • A disk failure on the central server risks data loss

Distributed version control system — Git

Instead of just taking a snapshot of the latest version of the file, the client mirrors the code repository completely. Distributed version control systems do not manage projects with differences between versions, they manage them with indexes (disk space is minimal so each client can put down a history of the entire project).

Advantage:

  • Development can also be carried out when the network is disconnected
  • The single point of failure of the server is avoided
  • Fast branch switching speed

Initial Configuration

After you download and install Git, you need to perform initial configuration on a computer that is using Git for the first time. Configure the Git working environment. The configuration only needs to be done once, and the current configuration will be used for future upgrades.

Configuration:

Using the git config command, you can configure or read related environment variables

The user name and email address, which are referenced each time Git commits (to a local repository), indicate who committed the update and are therefore permanently incorporated into history along with the update.

Configurations in the system that are universally applicable to all users:

The configuration file is stored in D:\Git\etc\ gitConfig

git config –system user.name “—-“

git config –system user.email ——-@—.com

Directory for storing configuration files: C:\Users\ dukkha.gitConfig

git config –global user.name “—-“

git config –global user.email ——-@—.com

Configuration files in the Git directory of the current project:

The configuration file is located in the.git\config directory of the project

git config user.name “—-“

git config user.email ——-@—.com

Each level of configuration overrides the same configuration at the top (top down, level up)

To check your existing configuration, use git config –list

Deleting Configuration Information

git config –global –unset user.email

git config –global –unset user.name

Linux Basic Commands

  • Clear: Clears the screen

  • PWD :print the current directory path. PWD :print working directory

  • Touch file name: Create a file in the current directory

  • Ls -a: view hidden files, ls: list show

  • Mkdir Directory name: create folder

  • Rm File name: Deletes the file

  • Rm -rf Directory name: Delete a non-empty directory (use caution)

  • Less file name: View file contents in paging mode (Q key to exit, space key and B key to turn pages)

  • cd .. : Returns to the upper-level directory

  • Echo ‘test Content ‘: outputs information to the console

  • Echo ‘test content’ > test. TXT: writes the contents after the arrow to the text file, which is created and written to the current directory.

  • Ll /ls: Tils subfiles & subdirectories in the current directory on the console

  • Find directory name: Tils descendant files & descendant directories in the corresponding directory on the console

  • Find directory name-type f: tils files in the corresponding directory on the console

  • Rm File name: Deletes a file

  • Mv Source file Rename file: Rename the file

  • Cat file URL: View the content of the corresponding file

  • Url of vim file: Select file for content editing

    • Press I to insert mode to edit the file
    • Press the esc key
    • Press: to execute the command

      • :q! Forced exit (no save)

      • :wq Save the changes and exit

      • :set nu Sets the line number

Initialize the new repository

  • git init

To start Git management for an existing project in the same directory as the project, descendant folders in that project folder cannot initialize the new repository again with Git init. After initialization, a.git directory is displayed under the current directory. All data and resources required by Git are stored in this directory. So far, we’ve just initialized all the files and directories in the existing architecture, but we haven’t started tracking any files in the project yet.

Git directory structure
hooks The directory contains client-side or server-side hook scripts;
info Contains a global exclusion file
logs Saving Log Information
objects Directories store all data content;
refs Directories store Pointers to submitted objects that point to data (branches)
config The file contains project-specific configuration options
description Displays the description of the warehouse
HEAD The file indicates the branch that is currently checked out
index The file holds staging area information

In the future, if you need to do some tasks (such as code validation) before submitting data, you need to put third-party tools in hooks, similar to callback in JS.

The configuration file is located in the.git\config file in the project directory

git config user.name “—-“

git config user.email ——-@—.com

Git object

At its core, Git is a simple key-value database. You can insert any type of content into the database, and it returns a key value by which the content can be retrieved again at any time.

The generated Git object is placed in a file named after the first two digits of the.git\objects\git object hash and the remaining digits of the hash.

Directly generating git objects from the contents of the workspace skips the staging area and puts them directly into the local library.

The underlying command to generate git objects:

  • Echo ‘test content’ | git hash – object – w – the stdin: -w option instructs hash – object commands stored data object; If this option is not specified, only the corresponding key value is returned. The –stdin (standard input) option indicates that the command reads from standard input; If this option is not specified, the path of the file to be stored must be specified at the end of the command.

    | : said another command execution

  • Git hash-object-w File path: Generate git objects and store them in a local library.

  • Git hash-object File path: only the key value of the corresponding file is returned. Git objects are not generated or stored in a local library. This command is only used to get the unique hash value generated for the content of a file (the hash value stays the same as the content of the file).

    The underlying commands that generate git objects are stored in the local repository after git objects are generated. It essentially makes a one-to-one correspondence (binding) between the file contents and the file hash values.

View the files in.git\objects\ :

  • find .git/objects -type f

View the file contents of a Git object:

  • Git cat-file -p githash

Check the data type of a Git object:

  • Git cat-file -t githash

    Git objects are key-value pairs consisting of key: value. Key is the hash value corresponding to the file content, and value is the file content. It is bloB data in Git.

Git cat-file -p githash = git cat-file -p githash = git cat-file -p githash = git cat-file -p githash You have to remember the hash value of a Git object, which is unrealistic. Also, the file name is not saved — we only save the contents of the file.

All of the above operations operate on a local database and do not involve staging

The tree object

The true project snapshot is essentially a tree object

What it does: Solves the problem of saving file names and also allows us to group multiple files together.

Files in.git\objects\ are stored by Git in a manner similar to UNIX file systems. Everything in.git\objects\ is stored as tree objects, which correspond to UNIX directory entries, and data objects, which correspond roughly to file contents, or commit objects.

A tree object contains one or more records (each record contains a sha-1 pointer to a Git object or subtree object, along with schema, class type, and file name information). A tree object can also contain another tree object.

Commands to generate tree objects:

  • Git update-index –add –cacheinfo File mode Git object hash value Git object name: This command simply binds the hash value and file name of the Git object from the above operation, and then pushes it into staging. This operation does not generate a new Git object or tree object.If an identical file name is already attached to the hash value of a Git object and pushed into the staging area, the contents of the staging area will be overwritten by the hash value of a different Git object.
    • The file mode is:
      • 100644, indicating that this is a normal file;
      • 100755, represents an executable file;
      • 120,000, that’s a symbolic link.
    • –add option: Because the file does not need –add for the first time in the staging area
    • — cacheInfo option: Since the files to be added are in a Git database, not in the current directory, all need to be –cacheinfo
  • Echo ‘new file > new. TXT | git update – index – add new. TXT: direct will just generate new. TXT file is pushed to the staging area. Git hash-object -w combines the path and name of the git hash-index –add –cacheinfo file with the git update-index –add –cacheinfo file mode.
  • Git write-tree: Creates a tree object by organizing one or more git objects in the staging area into a group, without clearing the staging area. The generated tree object also has a hash value.

View tree objects:

  • Git cat-file -p Specifies the hash value of the tree object

Commands to view the transient state:

  • Git ls-files-s: check the status of the staging area.

Git creates and records a tree object based on the state represented by the staging area (that is, the index area) at a given time, so that a sequence of tree objects can be recorded by repetition (at a given time). The tree object is an abstraction of the operation in the staging area, which is essentially a snapshot.

The problem with tree objects: It is possible to determine the content composition of a project version from tree objects; however, to reuse these snapshots, you must remember all three SHA-1 hashes. Also, you have no idea who saved the snapshots, when they were saved, or why.

Submit the object

Commit objects complement tree objects.

Each submitted object has its own hash value. The simultaneous submission object is chained.

The command to create the submitted object:

  • Git commit-tree treeHash -m “Commit tree” : Creates a new commit object based on the provided tree object and emits the hash value of the new commit object on stdout. Use git log to check the commit.

  • Echo ‘messages’ | git commit – tree, a tree object hash value: according to the specified value, a tree object SHA – 1, and the father of submit submit object (if there is one For the first time to do the staging area As there is no parent)

  • Echo ‘messages’ | git commit – object hash value – p tree tree tree hash value: according to the specified value, a tree object SHA – 1, and the father of submit submit object (if there is one For the first time to do the staging area As there is no parent)

    Messages: log description of the submitted object.

To view the submitted object:

  • Git cat-file -p Specifies the hash value of the submitted object

The format of the submitted object:

It starts by specifying a top-level tree object that represents the current project snapshot. Then author/submitter information (based on your user.name and user.email configuration, plus a timestamp); Leave a line blank and submit the comment at the end.

Low-level commands of three types of objects are summarized

  • Git hash-object -w file name git hash-object -w file name
  • Git update-index –add — cacheInfo File mode \ Git object hash name of the git object
  • git write-tree
  • Echo ‘messages’ | git commit – tree, a tree object hash value

Workspace file status

  • Tracked: files that were originally managed under version control, were recorded in the last snapshot, or had their git objects generated and pushed to staging, although they were not committed.

    Status of files tracked after working for a period of time:

    • Has been submitted
    • The modified
    • Has the staging

  • Not traced: Neither a snapshot from the last update nor the current staging area.

Senior command

  • Git init: Initializes the new repository

  • Git status: Determine the current state of each file

  • Git diff: Which updates are currently being made that are not staged, and the workspace and staging of the branch are compared differently

  • Git diff branch name: The workspace of the branch is different from the local library

  • Git diff –cached: See what updates are provisionally saved for the next commit

  • Git add file name and URL: After git add, you can specify the path of the file or directory to track. If it is a directory, it means that all files in that directory are tracked recursively. Git Add subtext means to put object files into staged area (e.g., add files into staged area) and mark documents that have not been tracked as tracked.

    If the same file is edited multiple times and a Git object is generated after each edit, the git object generated each time is unique. However, pushing each Git object into the staging area and using the same file name will overwrite it.

    The git add command is equivalent to the following two commands:

    • Git hash-object-w Specifies the file name
    • Git update-index –add — cacheInfo File mode \ Git object hash name of the git object

  • Git commit: This method launches a text editor to enter the description of the commit.

    Git commit — m “message XXX”

    Git commit

    When the staging area is ready to commit, make sure that there are any changes or new files that haven’t been added to Git yet, otherwise the changes won’t be recorded at commit time. So, before preparing to commit, check with git status to see if everything is temporarily saved, and then run git commit. At commit time, snapshots are recorded that are placed in the staging area, and any that have not been staging remain in the modified state and can be versioned for the next commit. Each time you run a commit, you take a snapshot of your project that you can return to later or compare.

  • Git commit -a -m ‘——‘ : skip the staging area Git skips the Git add step by automatically saving and committing all files that have already been tracked.

  • Git rm file name: Delete a file in your workspace (not in the recycle bin) and push the deletion into staging to generate a Git object, after which you simply commit. If you manually delete it, you need to manually gir add./ generate the Git object and push it into the staging area.

  • Git mv Original file name New file name Rename the files in the working directory and add the changes to the staging area

    This is equivalent to the following three commands:

    • $ mv README.txt README
    • $ git rm README.txt
    • $ git add README

  • Git log: Views historical commits

  • git log –pretty=oneline

  • git log –oneline

  • git reflog

  • git –version

branch

Branching means that you can separate your work from the development thread without affecting the development thread. The essence of a branch is a movable pointer to a submitted object, which may be pointed to by head.

git branch

  • Git branch name: Creating a branch based on the commit object to which the current branch points does not automatically switch to the new branch.
  • Git branch: If you run it without any arguments, you get a list of all the branches currently in use.
  • Git branch -d name: Deletes a branch. You cannot run this command on a branch to delete yourself. This is usually done by cutting to the master branch to delete another branch that needs to be deleted. You cannot delete branches that have not been merged.
  • Git branch -v: View the last commit for each branch
  • Git branch name commitHash: Create a branch and point it to the corresponding commit object
  • Git branch – merged: see which branches have merged into the current branch Branch did not * before the name in the list of branches often can use git branch – d deleted;
  • Git branch –no-merged: Attempts to delete branches in this list will fail using git branch -d. If you really want to delete the branch and lose the jobs, you can use the -d option to force it down;
  • Git log –oneline — decorate: Check to see what the current branch points to.
  • Git log –oneline –decorate –graph –all: View all branch records
  • Git config –global alias. alias “git command” : alias git commands

git checkout

  • Git checkout name: Switch to the name branch

  • Git checkout -b branch name: Create a branch and point the head to it. Git branch name git checkout name git branch name

    When switching branches, be aware that the files in your working directory will be changed. If you switch to an older branch, your working directory will revert to what it looked like when the branch was last committed. If Git can’t do this cleanly, it will forbid branch switching.

    If I create new files in a branch and manipulate those new files, but those files are not added to Git because they are newly created, in this case, if I want to switch to the master branch, I can switch, but at the same time, for git’s sake, New files that have never been managed by Git are switched along with the branch.

    If I modify some files in a branch that are already managed by Git, they are already managed by Git. In this case, these files are in the modified state. If I want to switch to the master branch, Git cannot switch to the master branch. You must commit under the current branch before switching.

    Pit: It is possible to switch branches if there are new files in the project that have never been tracked, or new files that have been temporarily saved but never committed, and the new files that have not been tracked will be switched along with the branch. But such operations can contaminate other branches

    Note when switching branches:

    • Switching branches changes the direction of the head pointer
    • Switching branches changes the workspace file directory structure
    • Switching branches changes the staging area contents

  • Git log –oneline –decorate –graph –all: Check the project fork history

  • Git merge branch name

    • Fast-forward merge: Since the commit to which the former master branch points is directly upstream of your current commit, Git simply moves the pointer forward. Because the merge operation in this case has no differences that need to be resolved
    • Typical merge: If a conflict occurs, resolve it –> Open the conflicting file and modify it. Add commit

If there is a need to switch branches in the middle of the work, we should store the existing work. Git stash apply: The work on the current branch is pushed onto a stack. Git stash pop: The top of the stack should be removed as soon as it is removed. Git stash apply + Git stash drop Git stash list: Check your stash

(Often asked in an interview)

Git checkout filename: you can use git checkout filename if you want to go back to the same file you had in the workspace when you last committed, instead of CTRL + Z. Note that after executing this command, you cannot go back to the less effective edit state. (The bottom layer overwrites the edit that the workspace did not retreat into the staging area with the contents of the file in the staging area.)

Git reset HEAD filename: git reset HEAD filename: this command is used to reset the contents of the staging area to the contents of the staging area when the last staging was committed. However, the workspace is not overwritten with the latest edits. If you want your workspace to go back to where it was the last time you committed, add git checkout — filename

Git reset –hard version number. After a commit to the local library, run this command to overwrite the contents of the current three areas with the workspace, staging, and repository contents corresponding to the version number.

Git reset –hard^ : Go back to the last commit quickly.

Note:

After a COMMIT on one branch, the file contents are the same for all three regions. If a new file is added to the workspace or a previously traced file is modified, but the file is not added to the staging area or is added to the staging area but not committed, the version rollback will cause the new file or modification to be lost.

Git commit –amend, give the user another chance to amend the comment

Git reset –soft commithash –> Reset the HEAD with the contents of commithash.

Git reset [–mixed] commithash –> Git reset [–mixed] commithash —

Git reset –hard commithash –> Reset the working directory with the contents of commithash

Path to the reset

All path reset omit the first step! The first step is to reset the HEAD content. We know that the HEAD essentially points to a branch. The branch is essentially a commit object. HEAD can represent the state of a series of files! git reset [–mixed] commithash filename

Reset the staging area with the contents of Filename in Commithash

Checkout deep understanding

Git checkout brancname is the same as git reset –hard commithash. You need to reset the HEAD temporary working directory When you checkout HEAD, you’re not going to walk with the branch, you’re going to switch branches and reset –hard, you’re going to walk with the branch

Git checkout — filename resets the working directory

Git checkout commithash & git reset --hard commithash 1 Git checkout commithash --filename git checkout --filename Git checkout commithash <fileCopy the code

eslint

NPX eslint –init Checks js files NPX eslint directory names match rules: strings must use single quotation marks at the end of statements cannot have semicolons at the end of files must have newlines

Eslint combined with git

Json file: “husky”: {“hooks”: {“pre-commit”: “NPM run lint” // NPM run lint must be checked before git commit // Only if NPM run lint does not report an error}}

Git Workflow

A branch cannot be created without a commit for the project because the branch has no commit object to point to after it is created. A project must have a root commit before other branches can be created based on that commit.

Feature Branch and Hotfix Branch.

After development is complete, the branch is merged into the main branch and then deleted by the branch.

Two important branches:

  • The main branchmaster: used to store the release of the release, any time in this branch, is stable distribution
  • Development branchdevelop: Used for daily development, storing the latest development version.

Three ephemeral branches:

  • Feature Branch

  • Hotfix Branch

  • Release Branch

    They tend to be small branches that are separated from the development branch or main branch. Once development is complete, they are merged into Develop or Master and then removed.

Git re-associates the remote repository address

Three must understand the concept

Ensure that the local branch has traced the remote branch. 2. Pull data: git pull 3. Upload data: git push a local branch how to track a remote tracking branch 1. When cloning, it will automatically generate a local branch of the master (the corresponding remote trace branch has been traced). Git checkout -b git checkout --track Git checkout --track Change an existing local branch to a trace branch. Git branch -u Remote trace branch (remote/ branch nameCopy the code

The basic flow of remote collaboration

Step 1: The project manager creates an empty remote repository and operates on Github

The project manager creates a local repository git remote alias repository git init. Git add git commit

Git push alias branch git push alias branch git push alias branch git push alias branch git push A remote trace branch is generated after the push.

Step 6: Invite members and do it on Github

Git clone the local branch master and the remote trace branch alias /master are synchronized only when the clone is created

Git add git commit

Step 9: Members push their own changes to git push alias branches (enter username and password; A remote trace branch is generated after the push.

Git merge Git fetch alias git merge Git fetch alias git merge Git merge Git fetch alias

# # # for trackingCopy the code
Git checkout --track Remote trace branch (remote/ branch name) git branch -u Remote trace branch (remote/ branch name)Copy the code

push

git push
Copy the code

pull

git pull
Copy the code

pull request

Involve third party people in the fork of the projectCopy the code

Git push –set-upstream origin master

Git push: After the first push, you can use git push directly because –set-upstream was used for the first time

Git push -u origin master: git push -u origin master: git push -u origin master: git push -u origin master The remote repository is merged if it has one, and created if it does not.

Git push -u origin a: b: means to push branch A from the local repository to branch B from the remote repository. The remote repository is merged if it has one, and created if it does not.

Git remote add Origin: Connect the local repository to the remote repository. Origin is an alias that refers to the address of the remote repository.

Git remote -v: Displays the mapping between the local repository and its remote counterpart. A local repository can correspond to multiple remote repositories, but each remote repository corresponds to a different alias, which also represents a different remote address.

Git remote remove Specifies the alias of the remote repository

Git remote –help

There are three methods to change the remote repository address corresponding to the local repository: one: git remote set-url origin [url] git remote ste-url Alias of the remote repository New URL: Switch the remote repository address. Git remote rm origin Git remote add Origin [URLCopy the code

Git git

Management of empty project folders

Git will automatically ignore the management of a file directory if there is an empty directory in the project root directory, but the developer does not want this directory to be ignored. To do this, you can create a.gitkeep file in the empty directory that does nothing inside. The directory and the file are managed by Git.

Participate in other open source projects in Git

  • Issues can be submitted in the Github project
  • Fork warehouse to warehouse, open source project code in the clone to the local, and then to develop on their own after distal warehouse, then consider incorporating the fork down warehouse request to the source warehouse, in order to participate in other open source projects, can only qualify for the warehouse through the fork has submitted a merger to the source warehouse.

Description of the repository on Github

  1. Add technology stack to the warehouse, you can let others through keyword search to the warehouse
  2. The url of the warehouse product
  3. Publish static pages of the repository by creating a branch locally at —– gh-Pages, submit the branch to the online repository, and github will automatically generate a static website for you based on the branch (which contains JS, CSS and HTML).