The most common problems and operational summary list of Git

The most common problems and operational summary list of Git

introduction

Git problem finishing all paper work from many years of experience summary, are forgotten before the time to read through the operation, this time to re-order a bit, issued to facilitate the collection and the time needed to find the answer.

First, the necessary knowledge

 

56352098-1d71d700-6201-11e9-9c1b-2d1242749a49

 

warehouse

  1. Remote: Remote main warehouse;
  2. Repository: the local repository;
  3. Index: Git track tree, temporary storage area;
  4. workspace: local workspace (that is, your editor's code)

Two, git add submitted to the staging area, how do wrong

General Code for the submission process: Workspace ->  git status View Status ->  git add . all modifications to the staging area ->  git commit -m "提交描述" will submit code to your local repository ->  git push local warehouse code updates to remote repository

Scenario 1: Workspace

When you change the contents of a file chaotic workspace want direct discard modify the workspace with the command git checkout -- file.

// 丢弃工作区的修改
git checkout -- <文件名>
复制代码

Scenario 2: Temporary Area

When you change not only upset the contents of a file workspace, but also  git add when added to the staging area, to discard the changes in two steps, the first step command  git reset HEAD <file>, returned to the scene 1, scene operations by the second step 1.

// 把暂存区的修改撤销掉(unstage),重新放回工作区。
git reset HEAD <文件名> 
复制代码

Three, git commit submit to the local repository, error how to do?

1. Submission Information Error

Change the commit message

git commit --amend -m“新提交消息”
复制代码

2. Drain submitted

commit, the omission of submitting a partial update, there are two solutions:

  • Option One: once again commit

    git commit -m“提交消息”
    复制代码

    At this time, there will be twice the git commit

  • Option II: the missing documents submitted to commit before

    git add missed-file // missed-file 为遗漏提交文件
    git commit --amend --no-edit
    复制代码

    --no-edit It represents commit message does not change, only one submission on git

3. Submit error files, fall back on a version commit, then commit

git reset

Delete the specified commit

// 修改版本库,保留暂存区,保留工作区
// 将版本库软回退1个版本,软回退表示将本地版本库的头指针全部重置到指定版本,且将这次提交之后的所有变更都移动到暂存区。
git reset --soft HEAD~1

// 修改版本库,修改暂存区,修改工作区
//将版本库回退1个版本,不仅仅是将本地版本库的头指针全部重置到指定版本,也会重置暂存区,并且会将工作区代码也回退到这个版本 git reset --hard HEAD~1 // git版本回退,回退到特定的commit_id版本,可以通过git log查看提交历史,以便确定要回退到哪个版本(commit 之后的即为ID); git reset --hard commit_id 复制代码
git revert

Revocation of a particular operation before the operation and after commit and history are preserved, and the revocation of the

As a recent submission

// 撤销前一次 commit
git revert HEAD
// 撤销前前一次 commit
git revert HEAD^
// (比如:fa042ce57ebbe5bb9c8db709f719cec2c58ee7ff)撤销指定的版本,撤销也会作为一次提交进行保存。
git revert commit
复制代码

git revertSubmitted a new version will require reverta modified version of the content and then reverse back version is incremented, does not affect the contents of previously submitted

git revert And  git reset the difference between
  • git revertIs commit before with a new commit to rollback, git resetdirect delete the specified commit.
  • In this rollback operation point of view, the effect is the same. But there are differences in future continue to merge before the old version. Because git revertwith a reverse commit to submit before "and" so when the future consolidation of the old branch, resulting in this part of the changes will not occur again, but git resetis among the deleted some commit on a branch, and thus old when the branch merge again, these are rolled back commit should also be introduced.
  • git reset HEAD is to move back a bit, but git revertis HEAD go ahead and commit just the content of the new content and revert to the contrary, be content to be able to offset the revert.

Fourth, frequently used commands

1. Initial operation flow development git

  • The latest project code clone the main branch git clone 地址
  • Create a local branch git branch 分支名
  • Check local branch git branch
  • View remote branch git branch -a
  • Switching branch  git checkout 分支名 (generally uncommitted changes you can not switch, there is often a sensitive issue, can be forced to switch  git checkout 分支名 -f non must be used with caution)
  • The local branch push remote branch git push <远程仓库> <本地分支>:<远程分支>

2. git fetch

The update a remote host, the entire / retrieve local branch (at this time of renewed Repository) it retrieved the code has no effect on your local development code. For complete update to be merged or usegit pull

3. git pull

Pulling the remote host to update a branch, and then combined with the specified local branch (corresponding to a fetch operation plus the combined branch function)

4. git push

The update of the local branch, pushed to the remote host, the command format git pullis similar to

The branch operation

  • Use Git to download the specified branch command is:git clone -b 分支名仓库地址
  • Pull new remote branch git checkout -b serverfix origin/serverfix
  • Merge local branch  git merge hotfix:( merge the hotfix branch to the current branch)
  • Merge remote branch git merge origin/serverfix
  • Delete the local branch  git branch -d hotfix:( delete local hotfix branch)
  • Delete remote branch git push origin --delete serverfix
  • Upload the local branch of the newly named: git push origin newName;
  • Create a new branch: git branch branchName:( created called branchName local branch)
  • Switch to the new branch: git checkout branchName:( switch to branchName branch)
  • Create and switch branches: git checkout -b branchName:( merge more than the equivalent of two commands)
  • Check local branch:git branch
  • View all remote repository branch:git branch -a
  • Rename the local branch: git branch -m oldName newName
  • Rename local branch corresponding remote branch:git branch -m oldName newName
  • The local branch remote branch associated with the revised:git branch --set-upstream-to origin/newName

Fifth, optimize operations

1. Code pulling pull --rebase

In the teamwork process, suppose you and your companions in local, respectively, have their own new submission, and your companions ahead of your  push code to the remote branch, so you have to perform  git pull to get the submission companions before push their own It submitted to the remote branch.

The default policy in accordance with Git, if submitted chart between remote branch and the local branch of bifurcation, then (that is, not fast-forwarded), Git will be executed once  merge the operation, thus creating a record submitted does not make sense, resulting in as that kind of confusion on the map.

In fact, when the pull operation ,, use the  git pull --rebaseoption to solve these problems well. Plus the  --rebase effect of the parameters that the authors have forked line graph, then, Git will rebase strategy to replace the default merge strategy.

FIG assumed submitted before execution pull line is such that:

                 A---B---C  remotes/origin/master
                /
           D---E---F---G  master
复制代码

If you are performing  git pull after submission would this chart:

                 A---B---C remotes/origin/master
                /         \
           D---E---F---G---H master
复制代码

The results more out of  H this record did not submit necessary. If you are performing  git pull --rebase , then submit this chart will become:

                       remotes/origin/master
                           |
           D---E---A---B---C---F'---G'  master
复制代码

F G Two submitted by  rebase way of re-spliced  C after excess removed bifurcation, to achieve the purpose.

summary

Most of the time, use  git pull --rebaseis to enable the submission of charts look better, to facilitate code review.

However, if you are not very skilled to use git, then my advice is to  git pull --rebasepractice a few times before using it because rebase in git, the claim to be a "dangerous behavior."

In addition, it should also be noted that the use  git pull --rebaseeasier than pull directly lead to conflict, if conflict expected more, I suggest or direct pull.

note:

git pull = git fetch + git merge

git pull --rebase = git fetch + git rebase

2. Close the code merge --no-ff

The above  git pull --rebase strategy is to trim submitted object diagram, to form a straight line, which is soon to use the  git merge --no-ff <branch-name> strategy is chosen to act in the tract, filed deliberately come up line branching off FIG.

Suppose you ready to merge two local branches, and branches are just two fast-forwarded, then merge directly after you get a straight line graph of submission, of course, so no harm, but if you want to more clearly tell your partner : this series is submitted in order to achieve the same goal, then you can deliberately inflicted to the submission submission bifurcation diagram.

The implementation of  git merge --no-ff <branch-name> the results probably would be something like:

 

git go --no-ff

 

FIG intermediate circuit bifurcation clearly show these are submitted in order to achieve complete adjusting user domains and tags

Further

Often my habit, before merging branch (assuming that you want to merge local branch will feature dev branch), will first check whether the feature branch 'section behind "in remote dev branch:

git checkout dev
git pull # 更新 dev 分支
git log feature..dev
复制代码

If you do not submit any information output, it means that the feature for the dev branch is up-to-date is. If there is output and then immediately executed  git merge --no-ff , then, would this be submitted to chart:

 

git-go

 

So then before the merger, usually I will first execute:

git checkout feature
git rebase dev
复制代码

这样就可以将 feature 重新拼接到更新了的 dev 之后,然后就可以合并了,最终得到一个干净舒服的提交线图。

再次提醒:像之前提到的,rebase 是『危险行为』,建议你足够熟悉 git 时才这么做,否则的话是得不偿失啊。

总结

使用 git pull --rebase 和 git merge --no-ff 其实和直接使用 git pull git merge 得到的代码应该是一样。

使用 git pull --rebase 主要是为是将提交约线图平坦化,而 git merge --no-ff 则是刻意制造分叉。

六、SSH

1. 查看是否生成了 SSH 公钥

$ cd ~/.ssh
$ ls
id_rsa      id_rsa.pub      known_hosts
复制代码

其中 id_rsa 是私钥,id_rsa.pub 是公钥。

2. 如果没有那就开始生成,设置全局的user.name与user.email

git config --list // 查看是否设置了user.name与user.email,没有的话,去设置
// 设置全局的user.name与user.email
git config --global user.name "XX"
git config --global user.email "XX"
复制代码

3. 输入 ssh-keygen 即可(或ssh-keygen -t rsa -C "email"

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/schacon/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/schacon/.ssh/id_rsa.
Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub. The key fingerprint is: 复制代码

4. 生成之后获取公钥内容,输入 cat ~/.ssh/id_rsa.pub 即可, 复制 ssh-rsa 一直到 .local这一整段内容

$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== [email protected]
复制代码

5. 打开 GitLab 或者 GitHub,点击头像,找到设置页

6. 左侧找到 SSH keys 按钮并点击,输入刚刚复制的公钥即可

七、暂存

git stash 可用来暂存当前正在进行的工作,比如想 pull 最新代码又不想 commit , 或者另为了修改一个紧急的 bug ,先 stash,使返回到自己上一个 commit,,改完 bug 之后再 stash pop , 继续原来的工作;

  • 添加缓存栈: git stash ;
  • 查看缓存栈: git stash list ;
  • 推出缓存栈: git stash pop ;
  • 取出特定缓存内容: git stash apply stash@{1} ;

八、文件名过长错误

Filename too long warning: Clone succeeded, but checkout failed.

git config --system core.longpaths true
复制代码

九、邮箱和用户名

查看

git config user.name

git config user.email
复制代码

修改

git config --global user.name "username"

git config --global user.email "email"
复制代码

Ten, after .gitignore updates to take effect:

git rm -r --cached .
git add .
git commit -m ".gitignore is now working”
复制代码

XI synchronous Github fork out branch

1, configure remote, pointing to the original warehouse

git remote add upstream https://github.com/InterviewMap/InterviewMap.git
复制代码

upstream 2, the upstream branch warehouse acquired, and submission of information, which are stored in the local / master branch

git fetch upstream
# remote: Counting objects: 75, done.
# remote: Compressing objects: 100% (53/53), done.
# remote: Total 62 (delta 27), reused 44 (delta 9)
# Unpacking objects: 100% (62/62), done.
# From https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY # * [new branch] master -> upstream/master 复制代码

3, the master switch to the local branch

git checkout master
# Switched to branch 'master'
复制代码

4, the upstream / master branch into your master branch, local master branch will be in sync with the upstream repository, and do not lose local modifications.

git merge upstream/master
# Updating a422352..5fdff0f
# Fast-forward
# README | 9 -------
# README.md | 7 ++++++
# 2 files changed, 7 insertions(+), 9 deletions(-) # delete mode 100644 README # create mode 100644 README.md 复制代码

5, upload to your remote repository

git push 

Guess you like

Origin www.cnblogs.com/weilingfeng/p/11404459.html