Commonly used Git command operations at work

Summary of common Git commands

  A few days ago, I had a hard time, I was choking on drinking water, not to mention being choked by Git, it was not light, haha. So I plan to summarize my own use of Git-related things at work and discuss with you the experience of using Git. As a result, the article about Git is about to come out, summarizing and studying some difficult instructions and Git workflow, which will be updated slowly later.

Git commands

1. Alias ​​of Git

  1. First, let’s talk about the shorthand commands that I prefer to use, which can be configured according to the individual. The following figure is the shorthand for git commonly used in my own work:

  2. Use like this: git st --- View file commit status 

          git ci -m "commit information description" --- commit

          git br -d branchName --- delete local branch

          git co -b branchName --- cut off the new branch and jump to it

  Waiting for a series of shorthand operations, without typing a lot of instructions, it is efficient. Although it seems nothing, these operations are used very frequently in work. If we can use abbreviations, we can actually improve our office efficiency.

  (PS: But I have seen some colleagues with work experience still use git checkout, git status, git branch -d, etc., I don't know the reason)

  Welcome to add your own commonly used shorthand instructions, everyone can complement each other.

2. Description of common commands

   1. Basic development process

    The following are shorthand: st = status, co = checkout, br = branch, ci = commit

    git co -b BranchName -- cut out a new branch and enter development

    git st -- view the file modification status of the current branch

    git diff -- to see which files have been modified and which parts, the instructions can be followed by specific file paths

    git add "specific file path" -- add the file to the staging area

    git add . -- Use a dot "." at this time to add all the modified files to the staging area, which is convenient and quick.

    git ci -m "modification description" -- submit commit

    git pull origin BranchName -- Pull the remote branch code to the current branch. If there is a conflict, just resolve it.

    git push origin BranchName -- pushes the local branch code to the corresponding branch on the remote. (PS: If there is conflict resolution, you need to re-add and commit, and then push)

    The above is the commonly used process in the development process : branch into development -> check the status of the modified file after development -> diff to compare which parts of the file have been modified -> submit commit -> push to remote branch

   Explanation: a. If the function takes several days to develop, you can commit several times to prevent the developed code from being accidentally changed by yourself; git pull can also be replaced by git fetch and git merge.

    b. You can also use git stash and git stash apply to stage the modified code, so you don't have to perform add and commit in order to perform git pull.

    c. When multiple people are developing collaboratively, colleagues may submit code to the remote development branch every day; therefore, it is recommended to have more than one git pull operation per day, so that there will not be too many conflicts in the later merge.

  2. Basic git operations

    Since Git's instructions are powerful and complex, here are some commonly used operations. If you have your own better operation methods, you are welcome to add and improve them.

    Create and switch branches

     git co -b BranchName -- create a new branch and switch to it

     git br -d BranchName   -- delete a local branch (PS: when "-d" is replaced by "-D", it means forced deletion)

     git co -b branchName origin/remoteBranch -- New switch to this branch and associate the remote remoteBranch branch. (the more commonly used operations)

    push and pull operations

     git push origin :BranchName --Delete   the remote branch BranchName (the space is followed by an English colon; its meaning is to push an empty branch to the remote branch, which is easy to understand.)

     git push origin -d BranchName   -- this is also used to delete remote branches.

     git push origin localBranch:remoteBranch -- push the local branch to the remote branch, if the remote branch does not exist on the remote branch, the remote branch will be automatically created.

     git push origin remoteBranch -- can also be shortened to this. If the current branch is associated with a remote branch, you can use git push directly.

     git pull origin remoteBranch:localBranch --pull is similar to push, but the command is the value to pull the remote remoteBranch branch to the localBranch branch, the location relationship is just the opposite of push

     git pull origin remoteBranch -- pulls the remote remoteBranch branch to the current branch.

    branch merge

     git merge branchName -- merge the branchName branch into the current branch

     "git merge branchName --no-ff" -- Merge without fast-forward mode, a merge commit id will be generated after merging. 

     git merge origin/branchName -- merge remote branch

    Revocation of Workspace

     git co "file src" -- undo all changes in the workspace for a specific file. (It is only saving and not performing add and commit operations)

     git co . -- Undo changes to all files in the workspace. (also only without adding and commit)

    Staging Area -> Workspace

     git reset "file src" or git reset HEAD "file src" -- both refer to undoing changes in the staging area to the workspace.

     "git reset -- . " -- refers to withdraw all changes from the staging area to the workspace.

    git local repository commit -> workspace

     git reset --hard HEAD^ -- go back to the last commit (that is, the last commit)

     git reset --hard commitID --back to a specific commit.

    Staging operation

     git stash -- when you don't want to execute add and commit and need to switch branches or pull remote code urgently, use this command to temporarily store local changes

     git stash pop -- When the pull-related operations are performed and return to the branch, this command can restore the previously staged code.

    View commit history

     git log -- List details of each commit, including the committer's name.

     git reflog -- lists every detailed operation of the user, including switching branches, user commits and other information.

     "git log --oneline --graph --decorate --all" -- display commit information in the form of a command tree, (it's better to configure alias, so that you don't have to write so much. I configured: git tree)

    Compare Modification Differences

     git diff -- show the modified parts of all changed files.

     git diff "file src" -- show what parts of the file have changed.

     git diff commit1 commit2 --stat -- Compare the differences between the two commits.

     git diff commit1 commit2 "file src" -- Compare the modified parts of the file under these two commits.

  3. Development branch naming

    See a Gitflow article that borrows its rules for naming branches. Branches are defined according to different types of work, which are divided into feature branches, fixbugs branches, release branches, development branches and master branches  .

    I used to name branches mostly casually, or according to my own preferences. Now, branches can be named according to different types, such as

      A feature development branch can be feature-1.0,

      Fix bugs branch can make fixbugs-1.0,

      The release branch is called release-1.0,

      The development branch is called develop and so on.

The latter 1.0 can also be used to understand and distinguish English. Named in this way, it has the meaning of distinguishing itself from these branches and is easy to manage. I think this is a good way.

3. Tips

  1. I use VScode, I believe many people use it, it is lightweight, configurable, beautiful themes and many other advantages. When using the VScode editor, when the command line cd to the corresponding project, then use "code ." to enter VScode to automatically open the project. There are pictures and facts:

 

  Usually, for example, it happens to be on the command line, and the editor is just minimized by us, and it can be opened quickly by using "code ." directly. This is a little trick that I like to use. If you think it is good, go and try it.

  (PS: You can also use "open ." to open the folder corresponding to the project.)

Summarize

  Git commands are broad-minded. This article only introduces some of the most commonly used commands and tips, and some commands have not yet been involved, such as: fetch, rebase, revert, etc. I rarely use rebase myself, so I don’t dare to make more narratives to mislead others. If there are any mistakes or improvements in the text, please leave a message.

  PS: I feel that the length is a bit long. I don’t know if it will look boring. I welcome all gardeners to correct me.

  Links to related articles: https://juejin.im/post/5844507761ff4b006c3359a9   --Gitflow

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325172300&siteId=291194637