Git指令解释

最新推荐文章于 2025-03-06 09:47:09 发布

原创最新推荐文章于 2025-03-06 09:47:09 发布 · 168 阅读

0 ·

CC 4.0 BY-SA版权

其他专栏收录该内容

2 篇文章

订阅专栏

$ mkdir learngit//在当前目录下创建一个文件夹

$ cd learngit//进入learngit

$ pwd//显示当前路径

$ git init//将当前目录变为git可以管理的目录

$ git add hello.txt//提交变动到暂存区

$ git reset HEAD readme.txt//撤销暂存区的修改，并不会把修改工作区的内容

$ git commit -m “提交日志”//git的操作是以暂存库为准，只不过是提交变动到版本库后，暂存区版本库工作区都一样

$ git status//查看工作区与暂存区的变动（当没有变动可以看成暂存区版本库工作区都一样）

$ git diff readme.txt//查看具体的修改

$ git diff HEAD – readme.txt//查看工作区和版本库里面最新版本的区别

$ git reset --hard HEAD_{//硬回退到上一个版本,HEAD}_{表示上上个版本，HEAD}100表示往上100个版本

$ git reset --hard d7ecaba//硬重置到版本号前几位为d7ecaba的版本

$ cat readme.txt//查看文件里的内容

$ git log --pretty=oneline//精简输出到一行

$ git reflog//查看命令历史，可以用来恢复到某个历史版本

$ git checkout – readme.txt//可以丢弃工作区的修改：当你的修改没提交到暂存库时，回退的是版本库里面的（其实此时版本库和暂存库此文件一样的，git的操作是以暂存库为准，所以回退的还是暂存库里面的文件）；当你已经提交到暂存库了，git操作是以暂存库为准，所以回退还是暂存库里面的文件（此时还没提交到版本库所以版本库和暂存库里面此文件是不一样的）。

$ rm test.txt//删除工作区里的test.txt,$ git checkout – test.txt可以从暂存库里面记录的test.txt重置到工作区（举例：比如说你修改了test.txt后add到了暂存区后，你又修改了test.txt，但是不小心$ rm test.txt了，要是你用$ git checkout – test.txt回退得到的是add那次的修改，之后的修改会没了；当然你想恢复之后的修改那在这种情况下不要从暂存库回退，那该怎么做我也不知道）。我觉得要禁止用这条命令。

$ git rm test.txt//提交删除test.txt到暂存区，此时暂存区和工作区已经没test.txt,版本库还有。$ git checkout – test.txt恢复不了，因为暂存区没有test.txt了。想恢复它只有一个办法，先$ git reset HEAD readme.txt撤销暂存区的修改。此时用$ git status可以看到你的暂存区与工作区的不同，一个不同就是工作区删了test.txt。想恢复它到你的工作区还需要用$ git checkout – test.txt从暂存区拉取下来。

//如何在GitHub创建远程库

1.在你的电脑创建SSH KEY。
在用户主目录（C:\Users\你的用户名\）下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：
$ ssh -keygen -t rsa -C “youremail@example.com”
第一次创建会提示设置密码，设置密码时，密码不会显示出来。不设置密码就直接按下Enter键。
如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
2.将id_rsa.pub里面的内容添加到你在GitHub里面的SSH Keys。
3.在GitHub创建一个Git仓库。
4.在你的电脑的本地要推送的仓库下右键菜单，选Git Bash Here，输入如下命令：
$ git remote add origin git@github.com:xxx/xxx.git
5.把本地库所以的内容推送到运程库。
$ git push -u origin master
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令($ git push origin master)。

$ git clone git@github.com:xxx/xxx.git//从GitHub克隆一个库

$ git checkout -b dev//在当前节点创建分支并切换到新分支

$ git branch dev//在当前节点创建分支

$ git checkout dev//切换到dev分支

$ git branch//查看所以的分支，*所在指示当前分支

//合并分支处理冲突的方法

1.$ git merge dev//将dev分支合并到当前分支上，默认采用Fast-forward（快进模式）。
2.可以用$ git status查看冲突的文件，直接打开冲突的文件修改冲突。
3.然后提交修改$ git add readme.txt。
4.提交到版本库$ git commit -m “conflict fixed”。

//第二种合并分支的方法

$ git merge --no-ff -m “merge with no-ff” dev
合并分支时，加上–no-ff参数就可以用普通模式(递归模式)合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

//分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了；
合并后尽量把分支删除。

$ git log --graph --pretty=oneline --abbrev-commit//查看分支历史

$ git branch -d dev//删除dev分支

$ git stash//在当前分支创建储存库

$ git stash list//列出所以的储存库

$ git stash apply//恢复你的储存，但是stash里面的内容并不删除

$ git stash pop//恢复的同时把stash内容也删除

$ git stash drop//删除一个储存

$ git stash apply stash@{0}//恢复储存0(通过$ git stash list查看)，但是stash里面的内容并不删除

$ git stash pop stash@{0}

$ git stash drop stash@{0}

$ git cherry-pick 4c805e2//将一个特定的提交复制到当前分支（挑拣功能）

$ git branch -D test//如果要删除一个没有被合并过的分支，可以通过$ git branch -D test强制删除

$ git remote//查看远程库的信息，远程仓库的默认名称是origin

$ git remote -v//显示远程库更详细的信息，可以看到抓取和推送的origin的地址

$ git push origin dev//将dev分支推送到远程库对应的远程分支上//抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改。

1.现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆：
$ git clone git@github.com:xxx/xxx.git
当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：
$ git branch
2.现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：
$ git checkout -b dev origin/dev//切换到dev分支
3.现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：
$ git add env.txt
$ git commit -m “add env”
$ git push origin dev
4.你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：
$ cat env.txt
$ git add env.txt
$ git commit -m “add new env”
$ git push origin dev
5.推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把
最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
$ git pull
6.git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：
$ git branch --set-upstream-to=origin/dev dev
7.再拉取
$ git pull
8.这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：
$ git push origin dev
因此，多人协作的工作模式通常是这样
首先，可以试图用git push origin 推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin 推送就能成功！
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to origin/。