At school, one person may be in charge of the whole project from development to launch. However, in the company, because of the complexity and urgency of projects, one project is often implemented by more than one person, and there is a problem with code submission and code merging. Git and SVN. This article is about how git works and how to use it

  • Version Version control
  • Git account configuration
  • Creating a Git Repository
  • The principle of git
  • File operation command
  • Branch operation command

Pay attention to the public number, communicate together, wechat search search: stealth forward

Version Version control

  • Revision control is a technology used to review the history of changes made to a file, directory, or project during development, and to back up and restore the previous version
  • Without version control or without proper management of version control, many problems will be introduced in the software development process, such as the consistency of software code, redundancy of software content, concurrency in the software development process, security of software source code, and software integration

Git account configuration

  • Set the name and email address
# git config --global user.name "hello lwl"
# git config --global user.email [email protected]// Check the system config# git config --system --list// View the current user (global) configuration#git config --global --list// View the current repository configuration information# git config --local  --list
Copy the code

Creating a Git Repository

// Create a new Git repository in the current directory# git init// Clone a project and its entire code history (version information)# git clone [[email protected]:cscsss/learnHome.git]
Copy the code

The principle of git

  • Project file (Directory) : a Directory managed by Git, that is, a repository containing our WorkSpace and Git management space (.git).
  • Workspace (Workspace) : is usually stored in the project code place, a folder
  • Git management space (.git) : a directory for storing Git management information. It is automatically created when the repository is initialized. Which in turn contains an Index/Stage and a Repository
  • The staging area (Index/Stage) is used to store information about your temporary changes and to save information about the files to be submitted to the list. Can be used to save/restore temporary states in the WorkSpace
  • Repository: This is where you keep all the data you commit to all versions. Where HEAD points to the latest version put into the repository
  • Remote: A server that manages code that acts like a local repository, but is public

State transition process

  • Untracked: This file is only in the workspace, but it is not joined to the Git repository and does not participate in version control. The state became Staged through Git add
  • Unmodify: Indicates that the file snapshot in the repository is the same as that in the workspace. A file of this type has two variations, if it is Modified, and becomes Modified. If you move the library using Git RM, it becomes an Untracked file
  • Modified: The file has been Modified without any other operation. You can enter Staged state by using Git Add, and you can return to the unmodify state by discarding the modification using Git Checkout, which pulls the file from the library and overwrites the current modification
  • Staged: A Git commit synchronizes the changes to the repository, where the files in the repository and the workspace files are the same, and the files are in the Unmodify state. performgit reset branchName fileNameCancel temporary save. The file status is Modified

File operation command

Viewing file Status

// Check the status of all files# git status// Check the status of the specified file# git status [fileName]
Copy the code

Add files and directories

// Add the specified file to the staging area# git add [file1] [file2] ...// Add the specified directory to the staging area, including subdirectory files# git add [dir]
Copy the code

Remove files and directories

// Delete files from the staging area and workspace# git rm <fileName>// Delete fileName from the staging area and keep it in the current working directory# git rm --cached <fileName>
Copy the code

Commit the file to Git

// Submit the staging file to the local warehouse district# git commit -m [message]// Submit the file named fileName from the staging area to the local repository# git commit [fileName] -m [message]// Append the missed staging file. Git add. + git commit -m 'message'# git commit --amend -m [message] 
Copy the code

Check the file status and historical Git log

# git log// View the commit history
# git log--oneline // Displays the view commit history in thin mode
# git log-p <fileName> // View the submission history of the specified file
#Git blame 
Copy the code

Git diff compares the differences

// Display all the differences between the staging and working areas# git diff// Display the difference between the workspace and staging area in the filepath path file# git diff filePath// Show the difference between the filePath file and the HEAD branch in the workspace# git diff HEAD filePath// Shows the difference between the filePath file in the workspace and a commitId submission# git diff commitId filePath 
Copy the code

Git reset Rolls back the code

  • If you want to roll it back, you can use Git reset to reset the version number of the code. Git Reset has three modes. Soft, mixed and hard
// git reset [--soft | --mixed | --hard] [HEAD]
// git reset [--soft | --mixed | --hard] [commit]
#Git reset -- hard HEAD~3 // resets the last three commits as if they were never committed
#Git reset c7 c77bae2b0874be17b81a829cfb1237d9ce / 003444 / reset to 003444
Copy the code
  • – hard mode

When the current branch goes to a COMMIT, all new changes in the working directory and new changes that have been added to the stage staging area disappear. The workspace, index/stage, and repository are reset to the contents of the target commit, so the effect appears to be the same as clearing the staging and workspace

  • – soft mode

— Soft mode keeps the contents of the working directory and the staging area when resetting the HEAD, and puts any new differences caused by resetting the HEAD into the staging area, keeping the contents of the workspace and the index/stage. Only keep the contents of repository consistent with the reset node, between the original node and the reset nodeDifferences in changesIt’s going to be in the staging area (index/stage)

  • – mixed mode

Git reset defaults to –mixed if no parameter is used. Mixed mode preserves the contents of the workspace, but resets the contents of the index/stage in the Repository to be consistent with the reset node, so between the original node and the reset nodeDifferences in changesI’m going to put it in the workspace

git revert

  • If we want to undo an earlier version, but we want to keep the version after commitId is committed
# git revert -n commitId
Copy the code

Branch operation command

The new branch

// Create a new branch based on the current branch and switch to the new branch LWL# git checkout -b lwl// Create a new branch CSC based on originBranch# git checkout -b csc originBranch// Create a new CSC branch, but stay in the original branch# git branch csc// Switch to the CSC branch# git checkout csc 
Copy the code

git push

~~ Pushes all updates from the local branch to the remote repository master branch# git push origin master~~ Delete the remote branchname branch# git push origin -d <branchName>   
Copy the code

Delete the branch

# git branch -D <branchname>~~ Delete the local dev1 branch# git branch -D dev1 
Copy the code

Branch merge

  • The git-merge command is used to merge the branch from the specified commit(s)
#Git merge branchName // Merge the branch with branchName
#Git merge -m < MSG > 
      
        // Merge current branch with branchName commit and previous commit
      
#Git merge -- ABORT // Cancel the merge
Copy the code
  • When a merge conflict occurs, the department will use<<<<<<<.= = = = = = =and>>>>>>>Said. in= = = = = = =So the previous part is what’s happening on the current branch, at= = = = = = =The next part is the case of the other branch
  • Use it after resolving conflictsgit addAdd to index, and then usegit commitGenerate merge node

git pull/git fetch

  • Git Fetch can pull code from a remote repository
~~ Pull all the latest remote code# git fetch --all~~ Pull remote latest master branch code (specify master branch)# git fetch origin master 
Copy the code
  • The git pull. It not only pulls remote branches, but also merges remote and local code: git pull = git fetch + Git merge
~~ Pull remote warehouse branch, update and merge into local branch# git pull~~ Merges the remote master branch to the current local master branch# git pull origin master~~ Merges the remote master branch into the current local LWL branch. The colon is followed by the local branch# git pull origin master:lwl 
Copy the code

Git rebase merger

  • Git rebase master cancles every commit in the current branch curBranch and temporarily saves them as patches in the “.git/rebase” directory. Then update the curBranch branch to the latest commit for the master branch, and finally apply the saved fixes to the curBranch branch

  • In the process of rebase, conflicts may occur. In this case, Git will stop rebase and let you resolve the conflict; After resolving the conflict, use the git add command to update the index of the content. Then, you don’t need to perform git-commit, just executegit rebase --continue
#Git rebase branchName // merge branchName into current branch
# git rebase --continue// Continue merging after resolving the conflict
#Git rebase --abort // Cancel merge
#Git rebase -i HEAD~2 git rebase -i HEAD~2 It could be 3...
Copy the code
  • If git rebase master after. You need to move the current branch, curBranch, to master. You can use git merge again. The commit of the merged master is a linear commit

git tag

  • Tag corresponds to a commit, is a point, and is immovable. A branch is a series of commit points, a line with a HEAD pointer, and can be moved by the HEAD pointer. So, the difference between the two determines how to use it: branch if you change the code, tag if you don’t change the code
  • The branch is pushed to the remote branch, but the tag is not pushed to the remote branch. To push the tag to the remote branch, you need to run a separate tag push command
#Git tag 
      
        // Create tagName based on latest commitId
      
#Git tag -a 
      
         git tag -a 
        
#Git push origin 
#Git push --tags // Push all tags

#Git tag -d 
      
        // Delete the local tag
       
#Git push origin :refs/tags/ 
Copy the code

Welcome to correct any errors in the text

Refer to the article

  • Learn Git in an hour
  • Essentials for programmers: learn all aspects of Git commands
  • Git Reset has three modes