Git

The advantages of Git

1. Compared with SVN, Git is more suitable for distributed mode. After submitting code, it is not only uploaded to the cloud, but also has the corresponding local version library.

2.Git has a local repository, which can be committed many times locally. Once the development is complete, it can be pushed to the repository once, without affecting other developers. In addition, SVN UP needs to be performed in advance to submit the SVN. Therefore, conflicts may occur every time the SVN submits the SVN.

3.Git has better branch and merge support. A branch is actually a pointer, while a branch on SVN is a new directory.

4.Git is faster than SVN because the Git library is local, so local commit is ok, and push is a compressed file instead of each file being pushed.

How Git works

1. Record an overall snapshot. Git records differences on a file basis, whereas most other systems record differences on a file basis.

2. Maintain data integrity. All data needs to be verified before being saved to Git, and the result of the calculation is used as the unique identifier and index of the data. Git uses the SHA-1 algorithm to compute the data and checksum, calculating a SHA-1 hash on the contents of a file or the structure of a directory as a fingerprint string. The string consists of 40 hexadecimal characters. Everything in a Git database is indexed with this hash, not the file name.

3. Many operations only involve adding, not deleting. Because many operations are just adding data, most Git operations are reversible and don’t lose data as long as they commit regularly.

4. Three document states: Modified, staged and Committed. Modified: A file has been modified but has not been committed for saving; Passage Ten: Documents have been stored temporarily, and modified documents have been placed in lists to be saved next time you submit them; Committed: The file is saved to the local database.

5. The git directory. Git directory, used to hold metadata and object databases. The staging area is a simple file in a Git directory, also known as an index file.

6. Basic Git workflow.

   0. Modify some files in the working directory.
   1. Take a snapshot of the modified file and save it to the temporary storage area. (git add)
   2. Commit the update and save it forever. (git commit)
   3. Push to a remote server.

Common Operations on Git clients

0. Basic operations for creating a repository.

   0. You are advised to use HTTP or HTTPS. If you want to use SSH, add the SSH key to your profile.
   1. Git config –global user.name username
   2. Git config –global user.email user@email (Use the company’s internal email address)
   3. Git config –global credential.helper.store
   4. Copy the url. Copy the url, open your local git bash, and run git Clone to download it.
   5. The IDE extension opens. You can open this link with the vscode extension and download the project code locally to the specified location.

1. Check the current file status. Git status command. If nothing to commit, working Tree Clean is displayed, all files have not changed since the last commit.

2. Add a file directory.

   0. Start with git status to find the newly created file and directory. Untracked Files follows the new file and directory, which are Untracked.
   1. Use git add XXX to track a new XXX directory or file. At this point, the file or directory is in the transient state.
   2. Git commit -m XXX commit the contents of the staging area to the repository, and then use git status to find working Tree clean.
   3. You can use git push remote-name branch-name to push the local product to a remote repository. If remote-name branch-name is specified, you can use Git push.

3. Renames directory and file names.

   0. Using the Git status directive, you can see that renaming is essentially a process of removing old directories and files and adding new ones.
   1. Commit the rename to the staging area using git add XXX.
   2. Commit the rename using git commit -m XXX.
   3. Git push.

4. Modify the file content.

   0. After modifying the file, use git status to check the file status.
   1. Commit changes to the cache using Git add.
   2. Commit to the repository using git commit -m XXX.
   3. Also git push.

5. Update a file or directory.

   0. When updating to a consistent directory file on Gitlab, use the Git fetch or Git pull directive. The difference between the two is that both get updated versions locally from a remote location, while only the latter automatically merges.
   1. If you want to update to a particular version, you need to check the git log history to find the hash value for the version, and then git checkout hash_value can extract the corresponding version. (The hash value here is the unique index generated by sha-1.)
   2. When updated, the current code is the code of the specified version.
   3. You can commit to the local library, but not push to the remote server because it’s not on the same branch as the remote server.
   4. You can use Git checkout main to go back to the version of the main branch, at which point the corresponding hash value is not required.

6. Delete a directory or file.

   0. Git rm -r (-r allows recursive deletion if the directory name is the home directory name)
   1. Then commit push.

7. File restoration.

   0. Git Checkout can be rolled back if you just modify the file and do no other Git operations.
   1. Git checkout — XXX (XXX is the file name).
   2. I’ve changed it, I’ve added it, I’ve committed it. Git check –oneline git check –oneline git check –oneline

   Git revert If you want to revert to a particular version, you can use Git reset. If you want to revert to a later version, you can use Git revert.

8. View version history.

   0. Git log Displays all historical version information.
   1. Git log-x displays the latest x version information.
   2. Git log -x filename Displays x latest versions of a file (you need to go to the directory where the file resides to run this command).
   3. Git log — pretty=oneline — git log — git log — pretty=oneline — git log — git log — git log — pretty=oneline Author and date will not be included.

9. Filter the type of uploaded files. The touch. Gitignore command generates a.gitignore file, and then adds the file types to be ignored, but files that have already been traced cannot be ignored, even if they are added to the.gitignore file.

Iv. Branch management

0. Advantages of branching. You can update and retain the progress at any time to avoid the loss of work results and not affect the work progress of others. After completing your work, you can merge it into the main branch.
1. What are the branches. Essentially a mutable pointer to the COMMIT object, main being the default name for the branch. To create a new branch, create a pointer using the git branch command. After the commit, there is already a main pointer to the COMMIT object. Each commit is forward (back?) under the current pointer. Mobile.

3. Branch of current work. The HEAD pointer points to the current working branch, which can be viewed using git log.

4. What happens when you switch branches. Git checkout branchName is used to switch the HEAD pointer.

5. Branch creation and merge. Git branch branchName and Git checkout branchName can be implemented with git checkout -b branchName. Git merge newBranch git merge newBranch git merge newBranch git merge newBranch git merge newBranch git merge newBranch git merge newBranch git merge newBranch git merge newBranch (If you follow one branch to get to the other, you only move the pointer to the right when you merge two points, that’s a fast forward.) At this point the merged branch (newBranch) is no longer useful and can be deleted. If you change the same part of a file in different branches, git will merge but not commit and wait for you to resolve the conflict. Unmerged files are listed in the unmerged state, and Git adds the standard conflict resolution flag to the corresponding file.

6. Branch strategy. (Basic Principles)

   0. The main branch can only be used to publish new versions, and does not normally work on it.
   1. Normal development work is on the dev branch, so dev is not stable. After the test passes, it can be merged into Main, which publishes the new version of the development.
   2. For specific tasks such as new requirements and fixes, a new task branch should be created on the dev branch and merged into dev once completed.

7. Remote branch. Branches in remote repositories that cannot be moved and are updated only when Git interacts with the network. Representation of the remote branch: remote repository name/branch name. Use git remote -v to view remote repositories.

8. Trace remote branches. The local branch that comes out of the remote branch checkout is called the trace branch. That is, the local branch that is directly related to the remote branch is the trace branch. If you type push in the trace branch, Git will automatically match the corresponding branch of the server. You can also use Git pull to fetch all remote indexes and merge remote data into the local branch. When you clone the repository, Git automatically creates a branch called main to track origin/main. This is why push and pull instructions can be executed without additional arguments.

5.Git usage specification.

0. Basic usage process of version control software.

   0. Fork from the trunk remote repository to your own remote repository.
   1. Clone from your own remote repository to your local computer repository.
   2. Modify the file add new code and commit.
   3. Modify the file add new code and commit.
   4. Pull the latest code from the trunk remote repository.
   5. Merge the submissions from steps 3 and 4.
   6. Push to your own remote repository.
   7. Send merge requests from your own remote repository to the trunk remote repository.

1. Branch management strategy.

   0. The master branch. For release, user-facing delivery. Ensure consistency with the production environment.

   1. Development branch Develop. Only one, used for the first round of integration test of the project, not allowed to merge directly into the main branch, but used to merge functional branches and automatically build test packages. Be consistent with the development environment.

   2. Acceptance branch UAT. Only one, used for the second round of integration testing, always consistent with the UAT environment, after passing the test acceptance merged into the master.

   3. Temporary branches. Feature branch, hotfix branch.

   4. Functional branches. A branch of Develop for a specific function that needs to be merged into Develop.

   5. Repair branches. When the software is released and a bug occurs, separate a patch branch from the Matser branch to fix the bug, then merge it with the Master and Develop branches. Naming conventions: hotfix-*.

   6. Environment:

      0. Development environment:The server tested by developers during the development process has a brief configuration and frequent changes for the convenience of testing.
      1. Test environment:(also used for the Develop branch) a server where testers test, with a more formal configuration and predominantly white-box testing.
      2. Acceptance Environment (UAT) :The user experience server is the same as the production environment, but does not connect to the database.
      3. Production environment:On servers that provide services externally, error logs are enabled instead of error reporting.

   7. The tag. A tag has a unique name for a record of the current commit point. A tag is similar to a branch, but a branch can be viewed as a line of multiple tags (multiple commit). There is a HEAD pointer that can be moved based on the pointer, but a tag is a static point, a specific commit. So use branch when you need to change code, and just look at it and use tags.

2. Commit Message specification. (Written in readme)

   0. [scope]: [bug/story id]

   1. type:

      0. Fix: Fixes bugs.
      1. Feat: Added function.
      2. Test: debugging function.
      3. Style: Change code formatting or comments.
      4. Docs: changes documents.
      5. Refactor: Refactoring a function or method.

   2. Scope: used to define the scope of influence of type, data layer, control layer, view layer…

   3. Bug/Story ID: The number of the zen path bug or requirement involved.

   4. Subject: Short description, less than 60 words.

Solutions to common problems.

How to make code conflict less? Before development, pull up the latest code from the branch of the main warehouse and merge to resolve conflicts. When part of the functionality is complete, submit the merge request to merge the code into the main warehouse branch. Pull main warehouse branch code merge with local repository before committing merge to main repository.

one View code repository status: git status two Log:

View the log: git log

Git log –pretty=format:” XXXXX”

Run the git log -n command to query the latest n commit recordsGit log -p displays the difference between each commit: git log -pGit log –stat to view the modified file

Git log –grep string git log –grep string

3. Tracking file:

Create a newFIle: touch newFIle

To view and print all file names in the directory: ls Trace a file: git add newfile. CPPGit add. / git add * The former ignores the file types in the.gitignore, the latter does not.

Run the git rm -f XXX command to delete the trace file.

Delete the trace file but save it in your working directory: git re –cached XXX.

Four. submit

Git commit -m “XXXX”

Git commit -am “XXXX”Amend the last commit note: git commit — amend-m “XXXX”Go back to the first committed version and reset the staging area and working directory: git reset –hard HEAD^

Five. branch

Check out the branch: Git Branch

Rename branches: git branch -m old_branch new_branch

Git branch new_branch

Git checkout new_branch

Create and switch to a new branch: git checkout -b new_branch

The current state of cache: git Stash push

Revert to the previous state: Git Stash pop

Git mv oldxxx newxxx

Six. The label

Check the existing git tag

Tag the last commit with git tag v123

Git show v123

\