Git

Common commands

  • create
	git clone/ / clone (cloneGit init // create a new repositorylocal repository)
Copy the code
  • local changes
Git status // Check the changed filesinGit add. // Add all current changes to the temporary storage Git add <file> // Add some changes to the staging areain <file> to the next commit）
	git commit -m 'message'// Add committed information after committing to repository -mCopy the code
  • commit history
	git log// View show all commits, starting with newest) gitlogGit relog git relog git relogCopy the code
  • branches & tags
	git branch -aGit branch < name> // Create a new git branch-dGit checkout -b <name> // Create a branch and switch to a branch Git switch <name> // create and switch to a branch git tag <tagNameCopy the code
  • update & publish
git remote -v // list all currently configured remotes git remote show <remote> // show information about a remote git Fetch <remote> // Download all changes form <remote>, but don't integrate into HEAD git pull 
       
       
         // download changes form directly merge/integrate into HEAD git push 
         
         
           // publish local changes on a remote git push --tags // publish your tags
         
        
       
      Copy the code

== Difference between git fetch and Git pull == Git fetch: Obtains the latest version remotely and merges it to the local device

  • merge & rebase
Git rebase <branch> // rebase your current branch HEAD onto <branch>Copy the code
  • undo
Git reset --hard HEAD -- discard alllocal changes inGit revert <commit> // Undo an operationCopy the code

Refer to liaoxUEFeng.com

Usage of common commands

create
  1. Initialize a Git repository using the Git init command.git init
  2. To clone a Git repository, use the Git clone commandGit clone
Local related operations
  1. Add files to Git repository in two steps:
  • Git add < file > git add. Represents to add all files;
  • Deleting a file, manually deleting the file and using git rm < file> has the same effect as git add< file>
  • Run git commit -m to complete the task.
	git add .
	git commit -m 'Instructions for this Submission'
Copy the code
  1. Viewing workspace Status
  • Git status tells you that a file has been modified. Use git diff to check the changes.
	git status
	git diff
Copy the code
View history after submission
  1. Version back

  • The version that HEAD points to is the current version, so Git allows us to travel through the history of versions using the command Git reset –hard commit_id.

  • Before shuttling, you can view the commit history with git log to determine which version you want to fall back to. Add –pretty=oneline parameter: history information is more concise

  • To go back to the future, look at the command history with Git reflog to determine which version you want to go back to in the future.

	git reset --hard commit_id
	git reset --hard HEAD^
	git log
	git log --pretty=oneline
	git reflog
Copy the code
  1. Resolve the conflict
  • Use git log –graph to see the branch merge graph.
Branch dependent operation

  • Check out the branch: Git Branch

  • Git branch < name>

  • Git checkout < name>

  • Git checkout -b < name>

  • Git merge < name>

  • Git branch -d < name>

  • Git branch -d < name>

	git branch 
	git branch < name>
	git checkout < name>
	git switch < name>
	git checkout -b < name>
	git switch -c < name>
	git merge
	git branch -d < name>
	git branch -D < name>
Copy the code
Undo modify

Git checkout — file git checkout — file git checkout — file

  • One is that the file has not been put into the staging area since the modification. Now, undoing the modification will return the file to the same state as the repository.

  • One is that after the file has been added to the staging area, it has been modified. Now, undoing the modification will return the file to the status after it was added to the staging area.

  • Return the file to the state it was at the last Git commit or git add.

  • Git reset HEAD < file> can be used to unstage changes in the staging area and put it back into the workspace

    git checkout -- file

Git checkout — file git checkout — file Git checkout — file git checkout — file git checkout — file

Remote warehouse
  1. Remote clone

  • To clone a repository, you must first know its location and then use the git clone command to clone it.

  • Git supports several protocols, including HTTPS, but the native Git protocol supported over SSH is the fastest.

    git clone

  1. Associated remote warehouse

  • To associate a remote library, use the command git remote add origin git@server-name:path/repo-name.

  • After the association, run the git push -u origin master command to push all contents of the master branch for the first time.

  • Git push origin master can be used to push the latest changes whenever necessary after each local submission.

	git remote add origin
	git push
Copy the code

3. Pull code from distant branches

  • The git pull command fetches updates from a branch on a remote host and merges them with the specified branch on the local host
  • The git fetch command is used to fetch the latest version from a remote location to the local location
	git pull
	git fetch
Copy the code
Label management
  1. Create a label

  • The git tag < tagname> command is used to create a new tag. The default tag is HEAD. You can also specify a commit ID.

  • Git tag -a < tagname> -m “blablabla…” You can specify label information.

  • You can run the git tag command to view all tags.

  • Git show < tagname>

	git tag < tagname>
	git tag
	git show < tagname>
Copy the code
  1. Remove the label

  • Git push origin < tagname> can push a local tag;

  • Git push origin –tags can push all unpushed local tags.

  • Git tag -d < tagname> deletes a local tag.

  • The git push origin :refs/tags/< tagname> command can remove a remote tag.

	git push origin < tagname>
	git push origin --tags
	git tag -d < tagname>
	git push origin :refs/tags/< tagname>
Copy the code
Branch Management Strategy

  1. Branch strategy In practice, we should follow a few basic principles for branch management: First, the master branch should be very stable, that is, only used to release new versions, not normally work on it; So where do you work? All the work is on the dev branch, that is, the dev branch is not stable, and at some point, such as a 1.0 release, the dev branch is merged with the master branch, and the 1.0 release is released on the master branch. You and your friends are all working on the dev branch. Everyone has their own branch, so you can merge the dev branch from time to time by adding –no-ff to the dev branch. The fast Forward merger does not show that it has ever been done.

  2. BUG branch

    • When fixing bugs, we fix them by creating new bug branches, then merging them, and finally deleting them;

    • When the work in hand is not finished, first put a git stash on the work site, then go to fix the bug, and then go back to the work site with a Git stash pop. One is to restore with a Git Stash apply, but the stash content is not deleted. You need to remove it with a Git Stash drop.

    • Git cherry-pick < commit> if you want to merge a bug fix on the master branch into the current dev branch, you can use git cherry-pick < commit> to “copy” the bug commit to the current branch.

  3. Feature branch

    • To develop a new feature, it is better to create a branch.

    • If you want to drop a branch that has not been merged, you can forcibly delete it using git branch -d.

  4. Remote branch

    Therefore, the general working pattern for multi-party collaboration is as follows: First, you can try to push your own changes with Git push Origin < branch-name>;

    If the push fails, the remote branch is newer than your local branch and you need to use Git pull to try merging. If the merge has conflicts, resolve the conflicts and commit locally;

    Git push origin < branch-name>

    If git pull prompts no tracking information, the link between the local and remote branches has not been created. Git branch –set-upstream to < branch-name> origin/< branch-name>

    This is how people work together, and once you get used to it, it’s pretty easy.

    Conclusion:

    Git remote -v

    Branches created locally are not visible to others unless they are pushed remotely.

    If the push fails, use Git pull to grab the new commit from the remote branch.

    To create a branch corresponding to the remote branch, run the git checkout -b branch-name origin/branch-name command. The name of the local branch and the remote branch must be the same.

    Git branch –set-upstream branch-name origin/branch-name

    Grab branches remotely, using Git pull, and if there are conflicts, handle them first.