用 Git 一定要用命令行吗？用命令行一定高贵吗？
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了用 Git 一定要用命令行吗？用命令行一定高贵吗？相关的知识，希望对你有一定的参考价值。
Git其实不一定要用命令行的，可以用TortoiseGit（小乌龟Git）。
说实话在Windows上比用命令行来的方便，你可以完全不用操作命令行，当然要是懂一些命令自然会更方便不少。
常用的Git命令
查看、添加、提交、删除、找回，重置修改文件
git help <command> # 显示command的help
git show # 显示某次提交的内容 git show $id
git co — <file> # 抛弃工作区修改
git co . # 抛弃工作区修改
git add <file> # 将工作文件修改提交到本地暂存区
git add . # 将所有修改过的工作文件提交暂存区
git rm <file> # 从版本库中删除文件
git rm <file> —cached # 从版本库中删除文件，但不删除文件
git reset <file> # 从暂存区恢复到工作文件
git reset — . # 从暂存区恢复到工作文件
git reset —hard # 恢复最近一次提交过的状态，即放弃上次提交后的所有本次修改
git ci <file> git ci . git ci -a # 将git add, git rm和git ci等操作都合并在一起做git ci -am “some comments”
git ci —amend # 修改最后一次提交记录
git revert <$id> # 恢复某次提交的状态，恢复动作本身也创建次提交对象
git revert HEAD # 恢复最后一次提交的状态
查看文件diff
git diff <file> # 比较当前文件和暂存区文件差异 git diff
git diff <id1><id1><id2> # 比较两次提交之间的差异
git diff <branch1>..<branch2> # 在两个分支之间比较
git diff —staged # 比较暂存区和版本库差异
git diff —cached # 比较暂存区和版本库差异
git diff —stat # 仅仅比较统计信息
查看提交记录
git log git log <file> # 查看该文件每次提交记录
git log -p <file> # 查看每次详细修改内容的diff
git log -p -2 # 查看最近两次详细修改内容的diff
git log —stat #查看提交统计信息
tig
Mac上可以使用tig代替diff和log，brew install tig
Git 本地分支管理
查看、切换、创建和删除分支
git br -r # 查看远程分支
git br <new_branch> # 创建新的分支
git br -v # 查看各个分支最后提交信息
git br —merged # 查看已经被合并到当前分支的分支
git br —no-merged # 查看尚未被合并到当前分支的分支
git co <branch> # 切换到某个分支
git co -b <new_branch> # 创建新的分支，并且切换过去
git co -b <new_branch> <branch> # 基于branch创建新的new_branch
git co $id # 把某次历史提交记录checkout出来，但无分支信息，切换到其他分支会自动删除
git co $id -b <new_branch> # 把某次历史提交记录checkout出来，创建成一个分支
git br -d <branch> # 删除某个分支
git br -D <branch> # 强制删除某个分支 (未被合并的分支被删除的时候需要强制)
分支合并和rebase
git merge <branch> # 将branch分支合并到当前分支
git merge origin/master —no-ff # 不要Fast-Foward合并，这样可以生成merge提交
git rebase master <branch> # 将master rebase到branch，相当于： git co <branch> && git rebase master && git co master && git merge <branch>
Git补丁管理(方便在多台机器上开发同步时用)
git diff > ../sync.patch # 生成补丁
git apply ../sync.patch # 打补丁
git apply —check ../sync.patch #测试补丁能否成功
Git暂存管理
git stash # 暂存
git stash list # 列所有stash
git stash apply # 恢复暂存的内容
git stash drop # 删除暂存区
Git远程分支管理
git pull # 抓取远程仓库所有分支更新并合并到本地
git pull —no-ff # 抓取远程仓库所有分支更新并合并到本地，不要快进合并
git fetch origin # 抓取远程仓库更新
git merge origin/master # 将远程主分支合并到本地当前分支
git co —track origin/branch # 跟踪某个远程分支创建相应的本地分支
git co -b <local_branch> origin/<remote_branch> # 基于远程分支创建本地分支，功能同上
git push # push所有分支
git push origin master # 将本地主分支推到远程主分支
git push -u origin master # 将本地主分支推到远程(如无远程主分支则创建，用于初始化远程仓库)
git push origin <local_branch> # 创建远程分支， origin是远程仓库名
git push origin <local_branch>:<remote_branch> # 创建远程分支
git push origin :<remote_branch> #先删除本地分支(git br -d <branch>)，然后再push删除远程分支
Git远程仓库管理
git remote -v # 查看远程服务器地址和仓库名称
git remote show origin # 查看远程服务器仓库状态
git remote add origin git@ github:robbin/robbin_site.git # 添加远程仓库地址
git remote set-url origin git@ github.com:robbin/robbin_site.git # 设置远程仓库地址(用于修改远程仓库地址) git remote rm <repository> # 删除远程仓库
创建远程仓库
git clone —bare robbin_site robbin_site.git # 用带版本的项目创建纯版本仓库
scp -r my_project.git git@ git.csdn.net:~ # 将纯仓库上传到服务器上
mkdir robbin_site.git && cd robbin_site.git && git —bare init # 在服务器创建纯仓库
git remote add origin git@ github.com:robbin/robbin_site.git # 设置远程仓库地址
git push -u origin master # 客户端首次提交
git push -u origin develop # 首次将本地develop分支提交到远程develop分支，并且track
git remote set-head origin master # 设置远程仓库的HEAD指向master分支
也可以命令设置跟踪远程库和本地库
git branch —set-upstream master origin/master
git branch —set-upstream develop origin/develop
参考技术A
用git不一定要用命令行，用命令行不一定高贵，但是能提高效率呀。
附加一点小技巧，MAC下切换到zsh,打造有git提示的美化shell，提高效率：
git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
chsh -s /bin/zsh
但这都不是重点，git也好iTerm也好，这都是工具呀，没有高不高贵可言，关键是你借助他产出了什么。工具不是重点，作品才是啊。你敢说画图工具画出的作品一定比Photoshop产出的差？
我是一个低俗的人，但我的音乐绝不低俗。——莫扎特。
我觉得程序员就该使用命令行，熟记以下快捷键，将极大的提高你的命令行操作效率。
编辑命令
Ctrl + a ：移到命令行首
Ctrl + e ：移到命令行尾
Ctrl + f ：按字符前移（右向）
Ctrl + b ：按字符后移（左向）
Alt + f ：按单词前移（右向）
Alt + b ：按单词后移（左向）
Ctrl + xx：在命令行首和光标之间移动
Ctrl + u ：从光标处删除至命令行首
Ctrl + k ：从光标处删除至命令行尾
Ctrl + w ：从光标处删除至字首
Alt + d ：从光标处删除至字尾
Ctrl + d ：删除光标处的字符
Ctrl + h ：删除光标前的字符
Ctrl + y ：粘贴至光标后
Alt + c ：从光标处更改为首字母大写的单词
Alt + u ：从光标处更改为全部大写的单词
Alt + l ：从光标处更改为全部小写的单词
Ctrl + t ：交换光标处和之前的字符
Alt + t ：交换光标处和之前的单词
Alt + Backspace：与 Ctrl + w 相同类似，分隔符有些差别重新执行命令
Ctrl + r：逆向搜索命令历史
Ctrl + g：从历史搜索模式退出
Ctrl + p：历史中的上一条命令
Ctrl + n：历史中的下一条命令
Alt + .：使用上一条命令的最后一个参数
Git其实不一定要用命令行的，可以用TortoiseGit（小乌龟Git）。
说实话在Windows上比用命令行来的方便，你可以完全不用操作命令行，当然要是懂一些命令自然会更方便不少。
常用的Git命令
查看、添加、提交、删除、找回，重置修改文件
git help <command> # 显示command的help
git show # 显示某次提交的内容 git show $id
git co — <file> # 抛弃工作区修改
git co . # 抛弃工作区修改
git add <file> # 将工作文件修改提交到本地暂存区
git add . # 将所有修改过的工作文件提交暂存区
git rm <file> # 从版本库中删除文件
git rm <file> —cached # 从版本库中删除文件，但不删除文件
git reset <file> # 从暂存区恢复到工作文件
git reset — . # 从暂存区恢复到工作文件
git reset —hard # 恢复最近一次提交过的状态，即放弃上次提交后的所有本次修改
git ci <file> git ci . git ci -a # 将git add, git rm和git ci等操作都合并在一起做git ci -am “some comments”
git ci —amend # 修改最后一次提交记录
git revert <$id> # 恢复某次提交的状态，恢复动作本身也创建次提交对象
git revert HEAD # 恢复最后一次提交的状态
查看文件diff
git diff <file> # 比较当前文件和暂存区文件差异 git diff
git diff <id1><id1><id2> # 比较两次提交之间的差异
git diff <branch1>..<branch2> # 在两个分支之间比较
git diff —staged # 比较暂存区和版本库差异
git diff —cached # 比较暂存区和版本库差异
git diff —stat # 仅仅比较统计信息
查看提交记录
git log git log <file> # 查看该文件每次提交记录
git log -p <file> # 查看每次详细修改内容的diff
git log -p -2 # 查看最近两次详细修改内容的diff
git log —stat #查看提交统计信息
tig
Mac上可以使用tig代替diff和log，brew install tig
Git 本地分支管理
查看、切换、创建和删除分支
git br -r # 查看远程分支
git br <new_branch> # 创建新的分支
git br -v # 查看各个分支最后提交信息
git br —merged # 查看已经被合并到当前分支的分支
git br —no-merged # 查看尚未被合并到当前分支的分支
git co <branch> # 切换到某个分支
git co -b <new_branch> # 创建新的分支，并且切换过去
git co -b <new_branch> <branch> # 基于branch创建新的new_branch
git co $id # 把某次历史提交记录checkout出来，但无分支信息，切换到其他分支会自动删除
git co $id -b <new_branch> # 把某次历史提交记录checkout出来，创建成一个分支
git br -d <branch> # 删除某个分支
git br -D <branch> # 强制删除某个分支 (未被合并的分支被删除的时候需要强制)
分支合并和rebase
git merge <branch> # 将branch分支合并到当前分支
git merge origin/master —no-ff # 不要Fast-Foward合并，这样可以生成merge提交
git rebase master <branch> # 将master rebase到branch，相当于： git co <branch> && git rebase master && git co master && git merge <branch>
Git补丁管理(方便在多台机器上开发同步时用)
git diff > ../sync.patch # 生成补丁
git apply ../sync.patch # 打补丁
git apply —check ../sync.patch #测试补丁能否成功
Git暂存管理
git stash # 暂存
git stash list # 列所有stash
git stash apply # 恢复暂存的内容
git stash drop # 删除暂存区
Git远程分支管理
git pull # 抓取远程仓库所有分支更新并合并到本地
git pull —no-ff # 抓取远程仓库所有分支更新并合并到本地，不要快进合并
git fetch origin # 抓取远程仓库更新
git merge origin/master # 将远程主分支合并到本地当前分支
git co —track origin/branch # 跟踪某个远程分支创建相应的本地分支
git co -b <local_branch> origin/<remote_branch> # 基于远程分支创建本地分支，功能同上
git push # push所有分支
git push origin master # 将本地主分支推到远程主分支
git push -u origin master # 将本地主分支推到远程(如无远程主分支则创建，用于初始化远程仓库)
git push origin <local_branch> # 创建远程分支， origin是远程仓库名
git push origin <local_branch>:<remote_branch> # 创建远程分支
git push origin :<remote_branch> #先删除本地分支(git br -d <branch>)，然后再push删除远程分支
Git远程仓库管理
git remote -v # 查看远程服务器地址和仓库名称
git remote show origin # 查看远程服务器仓库状态
git remote add origin git@ github:robbin/robbin_site.git # 添加远程仓库地址
git remote set-url origin git@ github.com:robbin/robbin_site.git # 设置远程仓库地址(用于修改远程仓库地址) git remote rm <repository> # 删除远程仓库
创建远程仓库
git clone —bare robbin_site robbin_site.git # 用带版本的项目创建纯版本仓库
scp -r my_project.git git@ git.csdn.net:~ # 将纯仓库上传到服务器上
mkdir robbin_site.git && cd robbin_site.git && git —bare init # 在服务器创建纯仓库
git remote add origin git@ github.com:robbin/robbin_site.git # 设置远程仓库地址
git push -u origin master # 客户端首次提交
git push -u origin develop # 首次将本地develop分支提交到远程develop分支，并且track
git remote set-head origin master # 设置远程仓库的HEAD指向master分支
也可以命令设置跟踪远程库和本地库
git branch —set-upstream master origin/master
git branch —set-upstream develop origin/develop
参考技术C
用git不一定要用命令行，用命令行不一定高贵，但是能提高效率呀。
附加一点小技巧，MAC下切换到zsh,打造有git提示的美化shell，提高效率：
git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
chsh -s /bin/zsh
但这都不是重点，git也好iTerm也好，这都是工具呀，没有高不高贵可言，关键是你借助他产出了什么。工具不是重点，作品才是啊。你敢说画图工具画出的作品一定比Photoshop产出的差？
我是一个低俗的人，但我的音乐绝不低俗。——莫扎特。
我觉得程序员就该使用命令行，熟记以下快捷键，将极大的提高你的命令行操作效率。
编辑命令
Ctrl + a ：移到命令行首
Ctrl + e ：移到命令行尾
Ctrl + f ：按字符前移（右向）
Ctrl + b ：按字符后移（左向）
Alt + f ：按单词前移（右向）
Alt + b ：按单词后移（左向）
Ctrl + xx：在命令行首和光标之间移动
Ctrl + u ：从光标处删除至命令行首
Ctrl + k ：从光标处删除至命令行尾
Ctrl + w ：从光标处删除至字首
Alt + d ：从光标处删除至字尾
Ctrl + d ：删除光标处的字符
Ctrl + h ：删除光标前的字符
Ctrl + y ：粘贴至光标后
Alt + c ：从光标处更改为首字母大写的单词
Alt + u ：从光标处更改为全部大写的单词
Alt + l ：从光标处更改为全部小写的单词
Ctrl + t ：交换光标处和之前的字符
Alt + t ：交换光标处和之前的单词
Alt + Backspace：与 Ctrl + w 相同类似，分隔符有些差别重新执行命令
Ctrl + r：逆向搜索命令历史
Ctrl + g：从历史搜索模式退出
Ctrl + p：历史中的上一条命令
Ctrl + n：历史中的下一条命令
Alt + .：使用上一条命令的最后一个参数
Git 是一个分布式版本控制系统，保存的是文件的完整快照，而不是差异变化或者文件补丁。
保存每一次变化文件的完整内容, Git 每一次提交都是对项目文件的一个完整拷贝，因此你可以完全恢复到以前的任一个提交而不会发生任何区别。如果文件没有变化，它只会保存一个指向上一个版本的文件的指针，即，对于一个特定版本的文件， Git 只会保存一个副本，但可以有多个指向该文件的指针。
未变化的文件只保存上一个版本的指针。
Git 工程有三个工作区域：工作目录，暂存区域，以及本地仓库。工作目录是你当前进行工作的区域；暂存区域是你运行git add命令后文件保存的区域，也是下次提交将要保存的文件；本地仓库就是版本库，记录了你工程某次提交的完整状态和内容，这意味着你的数据永远不会丢失。
Git基于SHA-1 校验和，是一套内容寻址文件系统。Git 将文件的 SHA-1 校验和作为指针，目的都是为了唯一区分不同的对象。其中有三种模型：文件(blob)对象，树(tree)对象，提交(commit)对象。blob 对象保存的仅仅是文件的内容，tree 对象更像是操作系统中的文件夹，它可以保存blob对象和tree 对象。commit 对象的格式很简单：指明了该时间点项目快照的顶层tree对象、作者 /提交者信息（从 Git 设置的 user.name和 user.email 中获得)以及当前时间戳、一个空行，上一次的提交对象的 ID 以及提交注释信息。
Git 鼓励在工作流程中频繁使用分支与合并，哪怕一天之内进行许多次都没有关系。因为 Git 分支非常轻量级，不像其他的版本控制，创建分支意味着要把项目完整的拷贝一份，而 Git 创建分支是在瞬间完成的，而与你工程的复杂程度无关。
Git 的默认分支是 master ，存储在.git\\refs\\heads\\master文件中。
Git 的默认分支是 master ，存储在.git\\refs\\heads\\master文件中，假设你在 master 分支运行git branch dev创建了一个名字为dev的分支，那么 git 所做的实际操作是：
1. 修改.git文件下的HEAD文件为ref: refs/heads/<分支名称>。
2. 按照分支指向的提交记录将工作区的文件恢复至一模一样。
HEAD文件指向当前分支的最后一次提交
总结
1. Git 保存文件的完整内容，不保存差量变化。
2. Git 以储键值对（key-value）的方式保存文件。
3. 每一个文件，相同文件的不同版本，都有一个唯一的 40 位的 SHA-1 校验和与之对应。
4. SHA-1 校验和是文件的指针， Git 依靠它来区分文件。
5. 每一个文件都会在 Git 的版本库里生成blob对象来保存。
6. 对于没有变化的文件， Git 只会保留上一个版本的指针。
7. Git 实际上是通过维持复杂的文件树来实现版本控制的。
8. 使用 Git 的工作流程基本就是就是文件在三个工作区域之间的流动。
9. 应该大量使用分支进行团队协作。
10. 分支只是对提交对象的一个引用。
最后我还是强烈推荐命令行，如果喜欢高亮的配置一下Item2，如果非常喜欢GUI的那就推荐一下SourceTree吧，UI比较好看，还是大厂Atlassian出品。
走近设计模式：写代码一定要用设计模式吗？
摘要：不少人对设计模式都有些疑问或者说是质疑：写代码一定要用设计模式吗？用了设计模式的代码就比没用的好吗？
本文分享自华为云社区《走近设计模式：写代码一定要用设计模式吗？》，原文作者：技术火炬手 。
不少人对设计模式都有些疑问或者说是质疑：
- 写代码一定要用设计模式吗？
- 用了设计模式的代码就比没用的好吗？
为了解答第一个问题，我们需要去调研一下什么是设计模式，这包括了解设计模式产生的初衷、设计模式能否帮我们解决软件问题等；而为了解答第二个问题，就需要去掌握如何使用设计模式，何时何地使用何种设计模式，什么时候应该使用、什么时候需要远离。
什么是设计模式？
前段时间面试候选人的时候问过这个问题——“什么是设计模式？”。候选人答到，“设计模式有单例模式、观察者模式、代理模式......“。我没有打断他，还是顺着问了他对这几个模式的理解。虽然这并不是我想问的，但我猜测会这样回答的人应该不在少数。
“设计模式”或者是“Design Patterns”，无非是一种设计的模式，设计这里是指软件设计，再具体一点是“面向对象的软件设计”，而模式这个概念比较笼统，各行各业都有模式，用白话说就是一种“套路”，是一种可以复制的经验。
提起设计模式，有一本绕不开的经典《设计模式：可复用面向对象软件的基础》，除了设计模式，还有一个副标题——可复用面向对象软件的基础，限定了复用和面向对象。书中首先是抛出了几个观点：
- 设计面向对象软件比较困难，而设计可复用的面向对象软件就更加困难。
- 有经验的面向对象设计者能做出良好的设计，而新手却无从下手。
- 不是解决任何问题都要从头开始，内行的设计者更愿意复用以前使用过的解决方案。
然后给出了一个不是很好理解的设计模式的定义：对用来在特定场景下解决一般设计问题的类和相互通信对象的描述。讲人话就是特定问题的可复用的解决方案。这里可复用的概念比较含糊，我更愿意理解为实际项目中总结出来的，解决特定问题的最佳实践。
这种最佳实践可以来自于他人总结，典型的来源是各种书籍和源码；还有一个更重要的来源便是自身软件开发经验的总结。
什么时候使用什么模式？
解决特定问题的最佳实践。显然解决问题A的最佳实践往往并不能解决问题B，至少不会是解决问题B的最佳实践，那么我想这里至少要面临两个问题：
- 某种设计模式解决的是什么问题？
- 我的问题等于某种设计模式解决的问题吗？
得到了上面两个问题的答案后，接下来的才是设计模式如何解决我的问题。
这两个问题是以我的思路提出来的，同时我也觉得这是两个很糟糕的问题，下面我会做说明。
首先，我并不建议新手直接学习如何使用各种设计模式，比如那23种。学习的结果往往是掌握了如何用编程语言实现某种设计模式，却对该设计模式解决了什么问题没有深刻的印象。这种先入为主会让学者觉得设计模式很简单，然后在实际的开发中为了使用模式而使用，并没有解决实际的问题。因为我是这么干的，所以觉得有更好的方式。
一个建议是，在新手阶段，按这个步骤去学习设计模式：
- 多花点时间去了解软件设计上有哪些常见的设计问题、疑难杂症
- 哪些问题已经有了最佳实践的解决方案，或者说设计模式，哪些还没有
- 深入体会设计模式解决该问题的过程，最好能亲身参与该过程
这个思路是先有问题后有模式，大脑中形成的思路是通过问题检索模式，而不是孤立的模式，或者是模式检索问题的回路。
到这里我们在看一下上面两个问题，是一种拿着答案找问题的思路。实际的场景应该拿着问题找答案。我们重新调整一下：
- 我要解决的问题是什么？
- 我的问题是否等于已经存在的问题A
- 是否有解决问题A的设计模式
通过学习有哪些常见的设计问题以及对应的模式，我们也只能回答问题3。
而问题1和问题2跟设计模式没有任何关系，却是能不能应用某种设计模式的第一步。这也是导致设计模式滥用的根源，同时也是很多人放弃设计模式的原因。
关于如何去回答这两个问题，小弟暂时没法给大家解答。分析问题的能力，可能需要时间的积累吧。
设计模式的牢笼
设计模式按解决特定问题的最佳实践来定义本身没有错，但往往有人陷进了设计模式的牢笼。
以GoF设计模式为例，虽然那23中设计模式是由比你我更加聪明的程序员总结出来的，但使用它们也不是没有代价的。
- 设计模式不是现成的代码，它不像类库可以直接使用
- 设计模式大都是解决代码扩展性的问题，但这里的扩展性真的是你需要的吗，是不是过度设计
- 设计模式提升扩展性的方式往往是增加抽象，这就牺牲了简单性
这里再看一下开篇的两个问题：
问：写代码一定要用设计模式吗？
答：不是，不是所有问题都有现成的解决方案。
问：用了设计模式的代码就比没用的好吗？
答：不是，也许更差。
学习设计模式的好处
虽然设计模式不是银弹，掌握设计模式也不一定能帮你解决你正面临的问题，但学习一下设计模式对你的软件开发工作还是大有裨益的，就算你永远不使用它。
如果不忽悠下读者学这个还是有点用的，那写后续的系列文章意义在哪......
1.应对面试中的设计模式相关问题
就很直接，如果你是被面试的，被问到的概率不低；如果你面试别人，可以用来考察下候选人的理解程度。
2.让读源码、学框架事半功倍
优秀的开源项目中类的个数都会比较多，类结构、类之间的关系极其复杂，常常调用来调用去。为了保证代码的扩展性，代码中会使用到很多设计模式，当然也不排除作者秀的嫌疑，但是如果你不懂设计模式，看开源代码经常摸不着作者的设计思路，看起来找不到北。
3.为你的职场发展做铺垫
公司里面code review，你连几个设计模式都说不出来，一看就不是“大牛”，嗯，就是这样的。
4.提升你的代码设计能力
这一点要看造化，但这是客观存在的，你总会遇到需要设计复杂系统的时候，早接触早准备。
以上是关于用 Git 一定要用命令行吗？用命令行一定高贵吗？的主要内容，如果未能解决你的问题，请参考以下文章