This is the 9th day of my participation in the August More Text Challenge. For details, see:August is more challenging

Version control

1.1 What is version control

Version control is a system for recording changes in the contents of one or more files for future reference to specific revisions. In a company, projects are generally developed as a team. In a team, every team member needs a copy of the same code, and everyone is developing different functions based on this code. In the process, quite a lot of problems will arise. For these problems, we can use version control to solve, so a lot of version control tools were born. Such as the market is more common CVS/SVN /git and so on.

1.2. Why version control

It allows you to backtrack a file, or even an entire project, back to a point in time. Even if you go through the whole project and delete the files, you can still easily restore the original appearance. But the extra work is minimal. You can compare the details of the changes in the document to find out who changed what last time, to find out what caused the weird problem, and who reported the defect when, and so on. Versioning goes deep into the programmer’s team, if your project does not have versioning:

  1. Code management chaos.
  2. Difficulty in resolving code conflicts.
  3. Causing bugs during code integration.
  4. The owner of the code cannot be granted permission control.
  5. Difficulty in releasing different versions of a project.

1.3 Classification of version control tools

There are two main types of version control tools on the market:

  1. Centralized version control system
  2. Distributed version control system

1.3.1 centralized version control system

Centralized version control systems such as CVS, SVN, and Perforce have a single, centrally managed server that holds revisions to all files, and collaborators connect to this server via clients to retrieve the latest files or submit updates. This has been standard practice in version control systems for many years.

This has brought a number of benefits, and now everyone can see some of what others on the project are doing. Administrators can easily control the permissions of each developer and manage a centralized version control system. Is much easier than maintaining a local database on various clients. There are two sides of the coin, good and bad. The most obvious downside to this is the single point of failure of the central server. If the server is down for an hour, no one can commit updates for that hour, and no one can work together. At the same time, it must be connected to the Internet to work. If it is in the LAN, the bandwidth is big enough and the speed is fast enough. However, if it is on the Internet, it may take 5 minutes to submit a 10M file if the speed is slow.

1.3.2 distributed version control system

Hence distributed version control systems. In such systems, like Git, BitKeeper, etc., the client does not just take a snapshot of the latest version of the file, but mirrors the code repository completely. This way, if any of the servers that work together fail, they can be recovered later using any of the mirrored local repositories. Because each extraction is actually a full backup of the repository.

A distributed version control system manages projects without storing differences between project versions. It stores indexes (requires very little disk space so that each client can hold the entire project history) compared to a centralized version control system,Distributed version control systems are much more secureBecause everyone has a complete version library in their computer, it doesn’t matter if one person’s computer breaks down, just copy one from someone else. In a centralized version control system, if the central server goes down, everyone can’t work. When you actually use a distributed version control system, actuallyRepository changes are rarely pushed between two people’s computers“Because maybe you’re not on the same LAN and the two computers can’t access each other, or maybe your co-worker is sick today and his computer doesn’t turn on at all. Therefore, distributed version control systems are usuallyThere is also a computer that acts as a “central server”, but the purpose of this server is only forConvenient “exchange” everyone’s modificationWithout it, everyone can work just as well, it’s just inconvenient to swap changes.

A brief history of Git

Git is the most advanced distributed version control system in the world. Like many great events in life, Git was born at a time of great strife and innovation. The Linux kernel open source project has a wide range of participants. The vast majority of Linux kernel maintenance work (1991-2002) was spent on the tedious business of submitting patches and keeping archives. By 2002, the entire project team had started using BitKeeper, a distributed version control system, to manage and maintain the code. In 2005, the commercial companies that developed BitKeeper ended their partnership with the Linux kernel open source community, and they took back the right to use BitKeeper for free. This forced the Linux open source community (and in particular Linus Torvalds, the creator of Linux) to learn a lesson and develop a version control system of their own. Since its inception in 2005, Git has matured to be highly usable while still retaining its original goals. It’s fast, it’s perfect for managing large projects, and it has an incredibly nonlinear branch management system that can handle complex project development requirements.

Install Git

2.1. Install on Windows

Git official website Windows version, after downloading the installation package, double-click the EXE installation package to install.

Once the installation is complete, you can use the command line Git tool (which already comes with an SSH client). The installation is successful if you right-click on the blank space of the desktop or any folder and the menu bar shown in the following figure appears.

When you click on the Git bash Here menu, you will see a terminal window where you can enter the command to see the version information.

git --version
Copy the code

2.2. Install on a Mac

Git official website Mac version, after downloading, you can see a DMG file, double-click to open the compressed file, you can see a file inside, double click the PKG file again, you can install, and then follow the boot and click the “Continue” button to complete the installation.

Git initialization

3.1 Initial Git configuration

Because Git is a distributed version control system, each machine must identify itself: your name and Email address. These two configurations are important because they are referenced every time Git commits to indicate who committed the update, so they are permanently included in the history along with the update. You can configure this by typing two commands on the Git command line:

Git config --global user.name "git config --global user.email" git config --global user.name "git config --global user.email"Copy the code

To check the existing configuration, run the following command:

git config --list 
Copy the code

3.2. Initialize the warehouse

To start managing an existing project with Git, simply go to the project’s directory and execute:

git init
Copy the code

Git is a directory where git keeps track of and manages the repository. All the data and resources that Git needs are stored in this directory. So far, we’ve only initialized all the files and directories in the existing framework, but we haven’t started tracking and managing any of the files in the project.

Git directory

  1. The hooks directory contains hook scripts for the client or server.
  2. Info contains a global exclusion file
  3. Logs Stores logs
  4. The Objects directory stores all data contents.
  5. The refs directory stores a pointer (branch) to the commit object to the data.
  6. The config file contains project-specific configuration options
  7. The description command displays the description of the warehouse
  8. The HEAD file indicates the branch that is currently checked out
  9. The index file saves the staging area information

Use Git

4.1. Use git commands to add text to the repository

Make a tag operation before adding. You actually add files to the cache first and then to the repository. Start by telling Git to give the file to Git for management

git add
Copy the code

Then tell Git to commit the file to the local repository

git commit -m "wrote a readme file"
Copy the code

After -m, enter the description of the submission. You can enter anything, preferably something meaningful, so you can easily find the change record from the history. Git commit will tell you that a file has been changed (our readme.txt file) and that two lines of content have been inserted (readme.txt has two lines of content).

Before performing the commit, perform the add operation first to avoid missing files

4.2. Workspace and staging area

Git Add file operation is required for cruD operation in Git. The low-level operation will add the operation file to a cache called the cache area. After the operation is completed, git commit operation will be used for unified submission and the edited file will be synchronized to the version in a unified manner.

< p style = “margin-top: 0pt; margin-top: 0pt; margin-top: 0pt; margin-top: 0pt; margin-top: 0pt; margin-top: 0pt;

4.3 Checking the Repository Status

How do I view the current status of a project? I was coding at my computer for a while, using Git to manage it, went to the bathroom, ate an apple, and came back to work. I couldn’t remember what I was doing with Git.

#Check the current Git repository status (check the file contents in the cache)
git status 
Copy the code

4.4 Viewing Logs

How can we remember in our minds what changes have been made to a file of thousands of lines each time, so there must be some command in the version control system that tells us the history.

git log
Copy the code

Git log displays the latest and farthest git commit logs. If you want to add –pretty=oneline to git log, you can add –pretty=oneline.

git log --pretty=oneline
Copy the code

As you can see, the commit ID is a long string of characters, not a number. The reason is that when two people work on the same code and commit to their respective local repositories, the same commit number corresponds to different changes. Using numbers like 1,2, and 3 does not guarantee uniqueness. Therefore, Git uses SHA-1 algorithm to generate unique identifiers to ensure global uniqueness. For example, programmer A and programmer B are responsible for developing a chat software together, using Git to version control. Git is distributed version control, where everyone has a repository. If Git version control uses numbers like 1,2, and 3 to generate version numbers, programmer A and Programmer B will have problems merging their code. Whose version 1 is it anyway? SVN is centrally versioned and has only one repository, so version numbers can start at 1,2, or 3. Git is distributed version control, everyone has a repository, so you can’t start with 1,2,3.

4.5. View the Differences

If a file is known to have been modified, it’s even better if you can see what has been changed. For example, if you come back from a two-week vacation abroad, you can’t remember how you changed your readme.txt, so you need to use git diff to read it:

#View file differences between different versions
git diff 
Copy the code

4.6 Version Rollback

Whenever you think the file has changed enough, you can ** “save a snapshot” **. This snapshot is called a commit in Git. Once you mess up your files or delete them by mistake, you can recover from the last commit and continue working, rather than losing months of work.

Git must know which version it is. In Git, the current version is referred to as HEAD, the previous version is HEAD^, and the previous version is HEAD^^. Of course, it is easier to write 100 ^ to 100 versions, so write HEAD~100.

If we want to go back to the previous version, we can use the git reset command:

git reset --hard HEAD^
Copy the code

Go back to the specified version

git reset --hard <commit id>
Copy the code

4.7 Undo the modification

Git checkout — filename can discard workspace changes: — followed by a space, such as:

git checkout -- readme.txt
Copy the code

This command means to undo all changes to the readme.txt file in the workspace. There are two cases:

  1. readme.txtHas not been placed in the staging area since the modification (git add), now undo the changes and return to the exact same state as the repository;
  2. readme.txtOnce you’ve added it to the staging area, you’ve made changes, and now you undo the changes and return to the state you were in after you added it to the staging area.

The idea is to return the file to the state it was in when it was last committed or git added.

The — in git checkout — file command, which is important, without –, becomes the “switch to another branch” command.

4.8. Delete a File

In general, you can delete files directly from the file manager, or you can delete files using the rm command:

git rm test.txt
Copy the code

4.9 Branch management

Git has a powerful branch management system, and it is recommended to use branches to solve various problems in the project development process.

4.9.1 Viewing branches

We can use the command to see the current branch.

git  branch
Copy the code

4.9.2 Creating a Branch

We can use commands to create branches.

Git Branch NameCopy the code

4.9.3 Switching branches

Git Checkout branch nameCopy the code

4.9.4 Creating and Switching branches

Git checkout -b branch nameCopy the code

4.9.5 Merge into current branch

Git merge branch nameCopy the code

4.9.6 Deleting a Branch

Git branch -d Specifies the name of a branchCopy the code

5. Push remote warehouse command

  1. Initialize the local repository
git init
Copy the code
  1. Set the user name and email address of the code cloud
Git config --global user.name "git config --global user.email" git config --global user.email"Copy the code

  1. Configure to ignore the submitted file.gitignore

  2. Add the project to the local repository

Git add. git commit -m "Project initialization"Copy the code
  1. Configure the remote repository request path
Git Remote Add Origin creates its own repository in the code cloudCopy the code
  1. Push the CRM project from the local repository to the remote repository
git push -u origin master
Copy the code
  1. A dialog box is displayed. Enter the code cloud account and password

6. Precautions for team development

  1. Each time the team members develop, they first push to their own remote branch
  2. Back up the code in place before each merge or push to the master branch
  3. After making sure that both your branch code and the master branch are error-free, push the local master to remote
  4. Before development, switch to the master branch and update the code to make sure it is the latest version. If there is any update, also back up the entire project, then switch to your branch and merge the master to your branch
  5. In addition to submitting your code to your branch, you must merge your code into the Master
  6. Again, back up the project before each merge or push to avoid code loss if an error occurs due to unskilled operation

✨ past review

  • How do you get 20K? ❤
  • Do you want to take a look at SpringBoot?
  • Still think Shiro is difficult (ii)?

Thank you for reading, I hope it can help you if there are flaws in the blog, please leave a message in the comment area or add my private chat in the profile of the home page, thank you for your advice