How can I put it? New recruits to the company will not be quick to use Git, more in-depth need to learn

You can look at it from three

Version Control

Before you learn Git, you need to understand the concept of version control!

(1) What is version control? Version iteration: Version manager

Revision Control is a software engineering technique that is used to manage the history of changes made to files, directories, or projects during development. It can be easily viewed, backed up, and restored to previous versions.

  • Realize cross-region multi-person collaborative development
  • To track and record the history of one or more files
  • Organize and include your source code and documentation
  • Statistical workload
  • Parallel development, improve development efficiency
  • Track and record the entire software development process
  • Reduce developer burden, save time, and reduce human error

In a word: Techniques for managing multi-person collaborative development projects

No version control or lack of the right process management, version control itself can introduce a lot of problems in the software development process, such as the consistency of software code, software redundancy, software process the content of the sex, the concurrency in the process of software development, software source code security and software integration, etc.

Multiplayer development must use version control, otherwise it will be expensive!

(2) Common version control tools

Mainstream version control tool is as follows: Git/SVN/CVS/VSS/TFS/Visual Studio Online version control products very much, now the most influential and most widely used is a SVN and Git.

(3) Version control classification

  • Local version control

    Record each update of the file, you can make a snapshot of each version or record a patch file, suitable for personal use, such as RCS.

  • Centralized version control -SVN

    All version data is stored on the server, and developers can either synchronize updates or upload their own changes from the server

    All version data is stored on the server, and users only have their previous synchronized versions locally. If they are not connected to the network, users cannot see the historical version, switch version verification issues or work in different branches. In addition, all data is stored on a single server, so there is a high risk that the server will be damaged and all data will be lost. Of course, you can back up data regularly, representing products such as SVN, CVS, and VSS

    Multiple commit code conflicts: update first before commit

  • Distributed version control -GIT

    All version repositories are synchronized to each user locally, so that all historical versions can be viewed locally, can be submitted offline locally, and can be pushed to the appropriate server or other user when connected to the network. Since all version data is stored for each user, all data can be recovered if only one user’s device is fine, but this increases the local storage footprint.

    Everyone has all the code, there are security risks, do not work due to server corruption or network problems (benefits)

(4) The main difference between GIT and SVN

SVN version control system, stored in a central server repository is centralized, while at work, use your own computer, so the first thing to get crime from a central server version, and then continue to work, after we had finished the work, need to put yourself as or pushed to the central server, centralized version control systems must be connected to the Internet to use, Especially high requirements for Internet broadband.

GIT is a distributed version control system. There is no central server. Everyone’s computer is a complete version repository. The method of coordination is like this: for example, you modify file A on the computer, and others also modify file A on the computer. In this case, both of you just need to push the modification to each other, and then each of you can see the modification of the other.

GIT is the most advanced distributed control system in the world.

Git history

Like many of the great things in life, Git was born at a time of great conflict. The Linux kernel open source project had a large number of participants, and most Linux kernel maintenance was spent on the tedious business of submitting patches and keeping archives (1991-2002). Until 2002, The entire project started with a proprietary distributed version control system, BitKeeper, to manage and maintain the code.

By 2005, the commercial companies that developed BitKeeper ended their partnership with the Linux kernel open source community and took back the Linux kernel community’s right to use BitKeeper for free. It forced the Linux open source community (and Linux creator Linus Torvalds in particular) to develop their own version of the system based on the lessons learned with BitKeeper, which became Git!

GIT is the most advanced distributed control system in the world

Git is free and open source and was originally developed to aid in Linux kernel development in place of BitKeeper!

Linus personal introduction

Git environment configuration

3.1 Software Download

It-scm.com/ open gIT-scm.com/ and download it-scm.com/.

Official download is too slow, you can use Taobao image download:

Npm.taobao.org/mirrors/git…

After downloading, brainless installation can be, always the next step!

How do I uninstall it?

1. Check environment variables and delete those related to GIT

2. Manage by using control panel or other tools

3.2 start the GIT

After successful installation, there will be GIT option in the start menu, there are 3 programs under the menu: any folder under the mail can also see the corresponding program!

**Git Bash: **Unix and Linux style command line

Git CMD: **Windows style command line

**Git GUI: **Git GUI is a graphical interface. It is not recommended for beginners to use Git

Linux simple instructions:

(1) CD: Change the directory

(2) cd.. : Roll back to the previous directory and go to the default directory

(3) PWD: displays the current directory path

(4) ls(ll) : lists all files in the current directory, but ll lists more detailed contents

(5)touch: Create a new file. For example, touch index.js will create an index.js file in the current directory

(6)rm: Delete a file, such as rm index.js

(7)mkdir: Create a directory, is to create a folder

(8)rm -r: Delete a folder, for example, rm -r SRC delete the SRC directory

(9)mv: move the file, such as mv index.html SRC index.html is the file we want to move, SRC is the target folder, of course, the file and folder must be in the same directory

(10)reset: remount terminal, clear screen

(11) the clear: clear screen

(12)history: View command history

(13) help: to help

(14) exit: exit

(15)#

3.3 the GIT configuration

All configuration files are saved locally

GIT config -l

GIT config –system –list

GIT config –global –list

User name and email must be configured, please note!

Git configuration files:

Git\etc\ gitConfig: gitconfig –system system level in Git installation directory

(2) C:\Users\Administrator\. Gitconfig: only applies to the configuration of the currently logged user, –global

This file will not be generated until the following command is set.

[user]
	name = hanpang8983
	email = [email protected]
Copy the code

You can directly edit the configuration file here and respond to the configuration file after setting the command

Set the user name and email address (user representation, required)

The first thing you need to do when installing Git is set up your username and email address, which is very important because this information will be used for every Git commit and will be embedded in your commit forever:

Git config --global user.email "[email protected]" #Copy the code

You only need to do this once, if you pass in the –global option, because Git will always use information to handle everything you do on your system. If you want to use a different name or email address for a particular project, you can run this command within that project without the –global option. In short, –global is used globally, not for a particular project.

Iv basic Git Theory (Core)

4.1 Work Area

Git has three local Working areas: Working Directory, Stage/Index, Repository or Git Directory. If the Remote Git repository (Remote Directory) is added, it can be divided into four working areas, and the conversion relationship between files in the four areas is as follows:

  • Workspace: Where you usually store the project code
  • Stage/Index: a staging area that temporarily holds your changes, but is actually just a file that holds information about the list of files to be submitted
  • RepositoryThe warehouse area (local repository) is where the data is stored. This is where the data you submitted to all versions is storedHEADThe version that points to the warehouse where the crime was stored
  • Remote Repository: A server that hosts code and can simply be thought of as a computer on your project team for Remote data exchange

The three local areas are exactly the versions that Head points to in the Git repository

  • Directory: A Directory managed with Git, that is, a repository containing our workspace and Git management space
  • Workspace: The directories and files that you need to version control with Git. These directories and files make up the Workspace.
  • .git: Hidden files, Git management information directory, automatically created when initialization repository
  • Index/Stage: temporary storage area or new area to be submitted, before submission entryRepositoryPreviously, we could store all updates in the staging area.
  • Local Repository: a Local Repository where the Head is only the current branch.
  • Stash: A working state storage stack for saving and restoring temporary states in the Workspace

4.2 Workflow

Git works like this:

1. Add or modify files in the working directory.

2. Place the files to be versioned in the temporary storage area.

3. Commit the files in the staging area to Git repository

Git therefore manages files in three states: Modified, Staged, and Committed

Git project construction

5.1 Creating a Working Directory and Common Commands

A Workspace is a folder that you want Git to help you manage. It can be your project directory or an empty directory. It is recommended not to use Chinese.

5.2 Setting up a local warehouse

There are two ways to create a local repository: one is to create a completely new repository, and the other is to clone a remote repository

Create a new repository using the root directory of your git-managed project

Create a Git repository in your current directory
$ git init
Copy the code

2, after executing the project, you can see that there is an extra. Git directory, which contains all the information about the version

5.3 Cloning a Remote Warehouse

1, another way is to clone the remote directory, because the remote server is still a complete mirror of the warehouse to the local

Create a Git repository in your current directory
$ git clone [url]
Copy the code

2. Clone GitHub resource code (or go to Gitee)

$ git clone http://github.com/DuGuQiuBai/Java.git
Copy the code

Git file operation

6.1 Four File states

Version control is the version control of a file. To modify or submit a file, first of all, the file must be in the current state. Otherwise, the file may be submitted back to the file that you do not want to submit now or the submitted file may not be submitted.

  • Untracked: Not traced, this file is in the folder, is not added to the Git repository, does not participate in the version control, passedgit addThe command changes the state toStaged
  • Unmodify: A file has been stored but has not been modified. That is, the snapshot content of the file in the version is exactly the same as that in the file. This type of file can be saved in two waysModified. If you are usinggit rmIf the version library is removed, it becomesUntrackedfile
  • Modified: The file has been modified, just modified without doing anything else, this file also has two places, throughgit addAccess to the staging areaStagedState, usinggit checkoutDiscard the modified content and returnUnmodifyState, this onegit checkoutThat is, take the file from the library and overwrite the current change!
  • Staged: Temporary status, rungit commitThe changes are synchronized to the library, at which point the files in the library and the local file become consistent again, and the file isUnmodifyState, executiongit reset head filenameCancel temporary storage. The file status changes toModified

View file status:

# check the status of the specified file
$ git status [filename]
Check the status of all files
$ git status
Add the specified file to the staging area
$ git add hello.java
Add all files to the staging area
$ git add .
# commit the contents of the staging area to the local repository
$ git commit -m "Submit message content"
Copy the code

Operation process

6.2 Ignoring Files

Sometimes we don’t want to put certain files in version control, such as data files, temporary files, design files, etc.

Create a. Gitgnore file in your home directory. This file has the following rules:

  1. Lines that ignore blank lines or the beginning of a hash sign (#) in the file are ignored
  2. Linux wildcards can be used. For example: asterisk (*) for any number of characters, question mark (?) stands for a character, square brackets ([abc]) represents an optional string range, curly braces ({string1,string2... }) represents optional strings, etc.
  3. If the name is preceded by an exclamation mark (!) indicates that the exception rule will not be ignored
  4. If the name is preceded by a path separator (/), indicating that the files to be ignored are in this directory, but files in subdirectories are not ignored
  5. If the name is followed by a path separator (/), indicating that subdirectories of this name in this directory are to be ignored, not files (default files or directories are ignored)
# comment
*.txt # ignore all.txt files
! Lib.txt # except lib.txt
/temp Only temp files in the root directory of the project are ignored
build/ Ignore all files in the build/ directory
doc/*.txt # ignore doc/notes.txt but not doc/server/java.txt
Copy the code

Refer to ignored files:

*.class
*.log
*.lock

# Package Files #
*.jar
*.war
*.ear
target/

# idea #
.idea/
*.iml

*velocity.log*
### STS ###
.apt_generated
.factorypath
.springBeans

### Intellij Idea ###
*.iml
*.ipr
*.iws
.idea
.classpath
.project
.settings/
bin/

*.log
tmp/

#rebel
*rebel.xml
 
Copy the code

Use the code cloud

  • Gitee.com register login code cloud to improve personal information

  • Configure the SSH public key binding on the local PC to implement password-free login

    SSH directory C: Users\Administrator\. SSH directory
Create public key
ssh-keygen -t rsa
# All the way to the next step
ssh-keygen -t rsa -C "[email protected]"
Copy the code

  • Add the public key information to the code cloud account

  • Use the code cloud to create your own repository

    License: Whether open source can be freely reproduced

8 Idea Integration with Git

1. Create a new project and bind GIT

  • Copy the remote GIT file directory into your project.

  • The color of the file is the selected state

2. Modify GIT files using IDEA

  • Add to staging area
  • Commit to submit
  • Push to the remote repository

3. Submit tests

Video description

Appendix: GIT branch

Branches are relatively difficult in GIT. Branches are like parallel showers in sci-fi movies. If two parallel showers don’t interfere with each other, it doesn’t affect you at all. At some point, though, two parallel universes merge, and we have some problems to deal with.

GIT branch:

# list all local branches
$ git branch
List all remote branches
$ git branch -r
Create a new branch, but remain in the current branch
$ git branch [branch-name]
Create a new branch and switch to that branch
$ git checkout -b [branch-name]
Merge the specified branch into the current branch
$ git merge [branch-name]
# delete branch
$ git branch -d [branch-name]
# delete remote branch
$ git push origin --delete [branch-name]
$ git branch -dr [remote/branch-name]

Copy the code

If multiple branches are executed in parallel, our code will not conflict, i.e. multiple versions exist at the same time!

If the same file is modified when merging branches, it will cause conflicts: ** The solution is that we can modify the conflicting file and resubmit it! ** Check whether you want to keep his code or yours. (Conflict requires negotiation code)

The master branch should be stable enough to release new versions, and generally allowed to work on it. It should normally work on the new dev branch, and when the work is done, for example, to release or the dev branch code is stable, it can be merged into the master branch.

This place belongs to the key question, need to have a small partner to test and play together, quick start can!

GIT daqo