Git和SourceTree一起使用没烦恼（骚）

Git常用命令 具体方法如下 开发人员常常遇到这种情况：花了几天时间一直在做一个新功能，已经改了差不多十几个文件，突然有一个bug需要紧急解决，然后给一个build测试组。在Git问世之前基本上靠手动备份，费时且容易出错。 git stash命令简而言之就是帮助开发人员暂时搁置当前已做的改动，倒退到改动前的状态，进行其他的必要操作（比如发布，或者解决一个bug，或者branch，等等），之后还可以重新载入之前搁置的改动，很cool吧？ 首先，用git add把所有的改动加到暂存区（staging area）。 接着用git stash把这些改动搁置。 到这里，当前工作平台就回复到改动之前了。该干嘛干嘛，此处省略1万字。 需要找回之前搁置的改动继续先前的工作了？ 也可以用 git stash list 来查看所有的搁置版本（可能搁置了很多次，最好不要这样，容易搞混） 在出现一个搁置栈的情况下，比如如果你想找回栈中的第2个，可以用 git stash apply stash@{1} 如果想找回第1个，可以用 git stash pop 如果想删除一个stash，git stash drop <id> 删除所有stash，git stash clear git搁置区操作： 还原所有文件，将服务器上的文件还原到本地，（适用于：还没有提交到本地git暂存区和本地git仓库里） 回滚操作（适用于：已经提交到本地git仓库里，还没有提交到远程git仓库里） --soft表示软连接：看不到git之前提交的信息，相当于从本地git仓库里面退回到本地git暂存区中，例如：  --hard表示硬链接：能看到git之前提交的信息，相当于直接回滚到远程git的历史提交某一次记录上。 重新提交git信息 强制提交到覆盖远程分支版本  拉取子模块代码 git 如何让单个文件回退到指定的版本【转】 git使用某一个分支完全覆盖另一个分支 删除本地git未跟踪文件和目录(未暂存文件)，只适用于本地新增文件和目录的操作 删除github中某个文件夹 Git 强制退回某一版本,Git回滚代码到某个commit 其他操作 git 删除某个中间提交版本   找到要删除的那条记录下面的提交记录hash值 之后弹出一个文件（类似：vi命令编辑文件） 将 pick 48bcfa87f 之前的 pick 改为 drop，保存文件（:wq!）。 之后用source tree重新推送另外一个分支名称到远程服务器，如果还用原来的分支名称是推不上去的。 在服务器上把原来的这个远端分支删了，把新推上来的远端分支名称改成之前删掉的分支名称（即：同名）。 客户端使用 source tree 先拉取新的同名的远端分支代码，在获取新的同名的远端分支代码。 获取代码把下面三个钩选上 关于commit log里面的hash提交记录：删除指定的记录之前的提交记录的Hash维持不变，删除指定的记录之后的提交记录的Hash会重新生成新的。 转： -resolve-conflicts/ 详解git pull和git fetch的区别（先要了解git pull和git fetch的区别） 前言 在我们使用git的时候用的更新代码是git fetch，git pull这两条指令。但是有没有小伙伴去思考过这两者的区别呢？有经验的人总是说最好用git fetch+git merge，不建议用git pull。也有人说git pull=git fetch+git merge，真的是这样吗？为什么呢？既然如此为什么git还要提供这两种方式呢？ 1. 相同点 首先在作用上他们的功能是大致相同的，都是起到了更新代码的作用。 2. 不同点 先补充一些git里面相关的一些知识： 首先我们要说简单说git的运行机制。git分为本地仓库和远程仓库，我们一般情况都是写完代码，commit到本地仓库（生成本地仓的commit ID，代表当前提交代码的版本号），然后push到远程仓库（记录这个版本号），这个流程大家都熟悉。 我们本地的git文件夹里面对应也存储了git本地仓库master分支的commit ID 和 跟踪的远程分支orign/master的commit ID（可以有多个远程仓库）。那什么是跟踪的远程分支呢，打开git文件夹可以看到如下文件： 其中head就是本地分支，remotes是跟踪的远程分支，这个类型的分支在某种类型上是十分相似的，他们都是表示提交的SHA1校验和（就是commitID）。 但是，不管他们是如何的相似，他们还是有一个重大的区别： 更改远端跟踪分支只能用git fetch，或者是git push后作为副产品（side-effect）来改变。我们无法直接对远程跟踪分支操作，我们必须先切回本地分支然后创建一个新的commit提交。  首先假设我们本地仓库的 master 分支上 commit ID =1 ，orign/mastter中的commit ID =1 ;这时候远程仓库有人更新了github ogirn库中master分支上的代码，新的代码版本号commit ID =2 ,那么在github上 orign/master的commitID=2，然后我们要更新代码。 1. git fetch 使用git fetch更新代码，本地的库中master的commitID不变，还是等于1。但是与git上面关联的那个orign/master的commit ID变成了2。这时候我们本地相当于存储了两个代码的版本号，我们还要通过merge去合并这两个不同的代码版本，如果这两个版本都修改了同一处的代码，这时候merge就会出现冲突，然后我们解决冲突之后就生成了一个新的代码版本。 这时候本地的代码版本可能就变成了commit ID=3，即生成了一个新的代码版本。 相当于fetch的时候本地的master没有变化，但是与远程仓关联的那个版本号被更新了，我们接下来就是在本地合并这两个版本号的代码。 2. git pull 是用git pull更新代码的话就比较简单暴力了，看下图。  使用git pull的会将本地的代码更新至远程仓库里面最新的代码版本 3. 总结 由此可见，git pull看起来像git fetch+get merge，但是根据commit ID来看的话，他们实际的实现原理是不一样的。 这里借用之前文献看到的一句话：  强制把服务器上的代码更新到本地，并且撤销本地所有操作。 　 gitlab处理合并请求： （dev分支为默认分支，允许所有者合并和所有者推送，不然本地dev处理完也无法提交服务器更改）   设置合并请求之前先运行流水线： 创建合并请求注意不要勾选接受合并请求之后删除源分支   合并请求时自动运行流水线 ①运行流水线成功，没有冲突就会直接出现合并按钮，删除源分支要根据实际情况决定选不选。 点击合并按钮之后，运行后续流水线操作 ②如果有冲突就需要进行冲突处理： 在服务器上执行将v3.6分支合并到dev分支的操作出现冲突，点本地合并按钮  弹出新的窗口，按照提示做就可以了 注意：本地执行git merge --no-ff "feature-v3.6"命令之后才能把冲突显示出来，本地执行git merge命令是在dev分支上进行的，不是在v3.6分支上进行的。 VS里面的git更改窗口进行合并操作 命令和sourcetree的操作方式参考： 刷新gitlab页面后，可以看到合并请求成功之后的界面。   删除github中某个文件夹