git - 查看远程仓库信息

经常发现好多时候修改线上代码的时候找不到原仓库地址了,头疼啊,还是git够强大,下面介绍下方法

可以通过命令 git remote show [remote-name] 查看某个远程仓库的详细信息，比如要看所克隆的 origin 仓库，可以运行：

$ git remote show origin
* remote origin
  URL: git://github.com/schacon/ticgit.git
  Remote branch merged with 'git pull' while on branch master
    master
  Tracked remote branches
    master
    ticgit

除了对应的克隆地址外，它还给出了许多额外的信息。它友善地告诉你如果是在 master 分支，就可以用git pull 命令抓取数据合并到本地。另外还列出了所有处于跟踪状态中的远端分支。

上面的例子非常简单，而随着使用 Git 的深入，git remote show 给出的信息可能会像这样：

$ git remote show origin
* remote origin
  URL: [email protected]:defunkt/github.git
  Remote branch merged with 'git pull' while on branch issues
    issues
  Remote branch merged with 'git pull' while on branch master
    master
  New remote branches (next fetch will store in remotes/origin)
    caching
  Stale tracking branches (use 'git remote prune')
    libwalker
    walker2
  Tracked remote branches
    acl
    apiv2
    dashboard2
    issues
    master
    postgres
  Local branch pushed with 'git push'
    master:master

它告诉我们，运行 git push 时缺省推送的分支是什么（译注：最后两行）。它还显示了有哪些远端分支还没有同步到本地（译注：第六行的 caching 分支），哪些已同步到本地的远端分支在远端服务器上已被删除（译注：Stale tracking branches 下面的两个分支），以及运行 git pull 时将自动合并哪些分支（译注：前四行中列出的 issues 和 master 分支）。

git 删除本地分支和远程分支、本地代码回滚和远程代码库回滚

【git 删除本地分支】

git branch -D br

 

【git 删除远程分支】

git push origin :br  (origin 后面有空格)

 

git代码库回滚: 指的是将代码库某分支退回到以前的某个commit id

【本地代码库回滚】：

git reset --hard commit-id :回滚到commit-id，讲commit-id之后提交的commit都去除

git reset --hard HEAD~3：将最近3次的提交回滚

 

【远程代码库回滚】：

这个是重点要说的内容，过程比本地回滚要复杂

应用场景：自动部署系统发布后发现问题，需要回滚到某一个commit，再重新发布

原理：先将本地分支退回到某个commit，删除远程分支，再重新push本地分支

操作步骤：

1、git checkout the_branch

2、git pull

3、git branch the_branch_backup //备份一下这个分支当前的情况

4、git reset --hard the_commit_id //把the_branch本地回滚到the_commit_id

5、git push origin :the_branch //删除远程 the_branch

6、git push origin the_branch //用回滚后的本地分支重新建立远程分支

7、git push origin :the_branch_backup //如果前面都成功了，删除这个备份分支

如果使用了gerrit做远程代码中心库和code review平台，需要确保操作git的用户具备分支的push权限，并且选择了 Force Push选项（在push权限设置里有这个选项）

另外，gerrit中心库是个bare库，将HEAD默认指向了master，因此master分支是不能进行删除操作的，最好不要选择删除master分支的策略，换用其他分支。如果一定要这样做，可以考虑到gerrit服务器上修改HEAD指针。。。不建议这样搞

管理修改

　　下面的内容需要你掌握暂存区的知识，我就默认你已经完全掌握了暂存区的概念。现在我们要讨论的是，为什么Git比其他版本控制系统设计得优秀？因为Git跟踪并管理的是修改，而非文件。 
　　为什么说Git管理的是修改，而不是文件呢？我们还是用小栗子说明一下。 
　　1.对readme.txt做一个修改，比如加一行内容：

cat readme.txt

• 1

 
　　2.添加：

git add readme.txt
git status

• 1
• 2

　　3.再修改readme.txt：

cat readme.txt 

• 1

 
　　4.提交：

git commit -m "git tracks changes"

• 1

　　5.提交后，再看看状态：

git status

• 1

　　到这里就会发现第二次的修改没有被提交。这是怎么回事啦？ 

　　让我们往回退一下看看前面的执行步骤： 
　　第一次修改 -> git add -> 第二次修改 -> git commit 
我们前面讲了，Git管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区准备提交，但是在工作区的第二次修改并没有被我们用git add命令放入暂存区，所以git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。 
　　提交后，用git diff HEAD – readme.txt命令可以查看工作区和版本库里面最新版本的区别：

git diff HEAD -- readme.txt 

• 1

　　从这里可以看出第二次修改确实没有被提交。 
　　那怎么提交第二次修改呢？你可以继续git add再git commit，也可以别着急提交第一次修改，先git add第二次修改，再git commit，就相当于把两次修改合并后一块提交了： 
　　第一次修改 -> git add -> 第二次修改 -> git add -> git commit 
现在你应该理解了Git是如何跟踪修改的，每次修改，如果不add到暂存区，那就不会加入到commit中。

撤销修改

　　我们往往会碰到一种情况就是修改完了之后才发现刚刚修改的地点被改错了，既然错误发现得很及时，就可以很容易地纠正它。比如我们刚刚在最后添加的哪一行错了，你可以删掉最后一行，手动把文件恢复到上一个版本的状态。如果用git status查看一下：

git status

• 1

　　Git会告诉我们，用git checkout – file可以丢弃工作区的修改：

git checkout -- readme.txt

• 1

　　命令git checkout – readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况： 
　　一种是readme.txt自修改后还没有被放到暂存区，撤销修改就回到和版本库一模一样的状态； 
　　一种是readme.txt已经添加到暂存区后，又作了修改，撤销修改就回到添加到暂存区后的状态。 
　　总之，就是让这个文件回到最近一次git commit或git add时的状态。现在，看看readme.txt的文件内容：

cat readme.txt

• 1

文件内容果然复原了。 
　　需要注意的是 git checkout – file命令中的–，没有–，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令

　　现在假定是凌晨3点，你不但写了一些胡话，还git add到暂存区了：

cat readme.txt
git add readme.txt

• 1
• 2

　　庆幸的是，在commit之前，你发现了这个问题。用git status查看一下，修改只是添加到了暂存区，还没有提交：

git status

• 1

　　Git同样可以帮你搞定，用命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区：

git reset HEAD readme.txt

• 1

　　git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。 
　　再用git status查看一下，现在暂存区是干净的，工作区有修改：

git status

• 1

 
　　还记得如何丢弃工作区的修改吗？

git checkout -- readme.txt
git status

• 1
• 2

　　这个时候也许可以睡一个安稳觉了，我是不是应该说句晚安啦。 
　　不过，假设你不但改错了东西，还从暂存区提交到了版本库，怎么办呢？还记得版本回退一节吗？可以回退到上一个版本。不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。还记得Git是分布式版本控制系统吗？我们后面会讲到远程版本库，一旦你把“stupid boss”提交推送到远程版本库，你就真的惨了

删除文件

　　在Git中，删除也是一个修改操作，我们通过一个小栗子来玩一把。先添加一个新文件test.txt到Git并且提交：

git add test.txt
git commit -m "add test.txt"

• 1
• 2

　　一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了：

rm test.txt

• 1

 
　　这个时候，Git知道你删除了文件，工作区和版本库就不一致了， git status命令会立刻告诉你哪些文件被删除了：

git status

• 1

　　现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

git rm test.txt
git commit -m "remove test.txt"

• 1
• 2

　　现在，文件就从版本库中被删除了。 
　　命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

　　另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

git checkout -- test.txt

• 1

　　git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。