当前位置： 首页 > news >正文

软件开发建设网站,个人是否可以做网站,ysl千人千色t9t9t9t9,做纸箱在什么网站找客户学习来自于#xff1a; 女朋友乱用Git#xff0c;差点把我代码删了。。。 一些常用的Git 知识点整理 关于Git这一篇就够了 Git基本命令大全 30分钟精通Git#xff0c;学不会来找我 Git 版本管理 | 莫烦PYTHON Git 代码版本管理教程 文章目录 【前言】集中式与分布式的…学习来自于 女朋友乱用Git差点把我代码删了。。。 一些常用的Git 知识点整理 关于Git这一篇就够了 Git基本命令大全 30分钟精通Git学不会来找我 Git 版本管理 | 莫烦PYTHON Git 代码版本管理教程 文章目录 【前言】集中式与分布式的区别git 介绍git 基本组成框架Workspace、Index / Stage、Repository、Remote 【常用 git 命令】新建文件添加到本地仓库git add、git commit -m改写提交git commit –amend查看历史提交日志git log回滚代码仓库git reset –hardgit 查看仓库信息git remote查看提交之后文件是否做了改动git status修改缓存区内容git add、git commit -m将改动文件添加到缓存区git add将所有改动文件添加到缓存区git add –all、git add .将文件撤销回到最近一次修改的状态git checkout – file查看单个文件可回滚版本git log filename查看提交历史git reflog删除文件git rmgit rm 后恢复文件git rm、git reset、git checkoutgit 创建分支git branch、git checkoutgit 查看分支git branch -agit 修改分支名称git branch -mgit 切换分支git checkoutgit 拉取远程所有分支git fetchgit查看不同分支的文件差异git diffgit 保存当前工作切换分支git stashgit 合并分支git mergegit 删除本地分支git branch –deletegit 删除远程分支git push origin –delete 【常用分支介绍】1 主分支 Master2 开发分支 Develop3 临时性分支3.1 功能feature分支3.2 预发布release分支3.3 修补 bugfixbug分支 【Git 版本管理 | 莫烦PYTHON】学习笔记1 Why Git?2 第一个版本库 Repository2.1 创立版本库init2.2 添加文件管理 (add)2.3 提交改变 (commit)2.4 流程图 3 记录修改log diff3.1 修改记录3.2 查看 unstagedno add与已 commit 的改变3.3 查看 staged已 add与已commit 的改变3.4 查看 staged unstaged HEAD的改变 4 回到从前rest4.1 修改已 commit 的版本4.2 reset 回到 add 前绿变红4.3 reset 回到 commit 之前staged to unstaged git log 【附录】git clone总是失败解决办法 【前言】 Git 是目前为止最好用的分布式版本控制系统。 大名鼎鼎的 github 用的就是 git 系统来管理它们的网站这里需要区分一下github 和 git 是两个东西github 是一个社区git 是一个服务系统github 只支持 git 分布式系统所以故名成为 github。 集中式与分布式的区别 除了 git 还有 svn、cvs 这样的版本控制系统它们的区别在于一个是分布式一个是集中式 集中式就是 svn 和 csv 这样的版本控制系统分布式是 git 区别在于集中式的版本控制系统每次在写代码时都需要从服务器中拉取一份下来并且如果服务器丢失了那么所有的就都丢失了你本机客户端仅保存当前的版本信息换句话说集中式就是把代码放在一个服务器上集中管理你的所有回滚等操作都需要服务器的支持。 分布式的区别在于每个人的电脑都是服务器当你从主仓库拉取一份代码下来后你的电脑就是服务器无需担心主仓库被删或者找不到的情况你可以自由在本地回滚提交当你想把自己的代码提交到主仓库时只需要合并推送到主仓库就可以了同时你可以把自己的代码新建一份仓库分享给其它人。 像集中式它们都有一个主版本号所有的版本迭代都以这个版本号为主而分布式因为每个客户端都是服务器git 没有固定的版本号但是有一个由哈希算法算出的 id用来回滚用的同时也有一个 master 仓库这个仓库是一切分支仓库的主仓库我们可以推送提交到 master 并合并到主仓库上主仓库的版本号会迭代一次我们客户端上的 git 版本号无论迭代多少次都跟 master无关只有合并时master 才会迭代一次。 git 介绍 工作区Working Directory 就是在电脑里能看到的目录比如 xxx-master 文件夹就是一个工作区。 版本库Repository工作区有一个隐藏目录 .git是 Git 的版本库。
在版本库中标记为 index 的区域为暂存区标记为 master 的是 Git 为我们自动创建的第一个分支代表的是目录树。 此时HEAD实际是指向master分支的一个“游标”所以图示的命令中出现HEAD的地方可以用 master来替换 图中的 objects 标识的区域为 git 的对象库实际位于.git/objects 目录下。 git 基本组成框架Workspace、Index / Stage、Repository、Remote Workspace开发者工作区也就是你当前写代码的目录它一般保持的是最新仓库代码。 Index / Stage缓存区最早叫 Stage现在新版本已经改成 index位于 .git 目录中它用来存放临时动作比如我们做了 git add 或者 git rm都是把文件提交到缓存区这是可以撤销的然后在通过 git commit 将缓存区的内容提交到本地仓库 Repository仓库区是仓库代码你所有的提交都在这里git 会保存好每一个历史版本存放在仓库区它可以是服务端的也可以是本地的因为在分布式中任何人都可以是主仓库。 Remote远程仓库只能是别的电脑上的仓库即服务器仓库。 远程仓库副本可以理解为存在于本地的远程仓库缓存。如需更新可通过 git fetch/pull 命令获取远程仓库内容。使用 fech获取时并未合并到本地仓库此时可使用 git merge 实现远程仓库副本与本地仓库的合并。git pull 根据配置的不同可为 git fetch git merge 或 git fetch git rebase。
【常用 git 命令】 新建文件添加到本地仓库git add、git commit -m git add test.c 将文件添加到缓存区 使用 git add 命令将文件添加到本地仓库的提交缓存这个时候还不算添加到了本地仓库我们还需要使用 git commit 命令为其添加修改的描述信息 注意在使用 git commit 时我们只需要简单描述一下我们做了什么不要像写注释那样写一大堆不然将来在回滚代码或者查看历史版本时很难审阅。 我们需要使用 -m 命令来简写描述我们的信息如果不使用 -m会调用终端的注释编辑器让你输入描述信息但是不建议使用因为注释编辑器比较难用不舒服。 git commit -m add new file \test.c\提交到本地仓库 git commit 会为我们生成 40 位的哈希值用于作为 id并把刚刚用 git add 添加到提交缓存区里的文件提交到本地仓库中便于我们回滚至此这个文件就已经添加到本地仓库中了同时本地仓库也迭代了一个版本。 git add 的灵活使用 git add [file1] [file2] … 添加一个或多个文件到暂存区 git add [dir] 添加指定目录到暂存区包括子目录 git add . 添加当前目录下的所有文件到暂存区
git add 和 git commit 两个步骤是否可以一步到位 git commit -a -m [message] 等价于 git add . git commit -m [message]更进一步简写为 git commit -am [message]
改写提交git commit –amend git commit –amend重写上一次的提交信息 我们提交了仓库但是发现写错了我们可以使用 –amend 长命令选项来改写提交 git commit –amend -m “提交描述” 修改 comment。 git commit –amend 会把暂存区的文件自动加入可以使用 -a 把工作区的文件也一起加入。 如果有一个新的文件修改也想提交到上一个commit中不改动描述信息 git add . git commit –amend –no-edit注意这里的之前指最近的 commit而且没有 push 到远程。 查看历史提交日志git log 第一行的 commit 是哈希算法算出的 id正如一开始所说分布式是没有一个主版本号的它们都是用 id 来做标志的同时用master 作为主仓库其它的分支怎么迭代都不会影响到 master head-master 代表这次提交到 master 主仓库如果是 head-分支仓库则代表提交到分支仓库 如果觉得 log 打印内容过多git log –prettyoneline 可以 简洁输出 查看某个人或者某几个人的提交 git log –authorJohn git log –authorJohn|Mary回滚代码仓库git reset –hard git reset –soft id # 就仅仅将头指针恢复已经add的暂存区以及工作空间的所有东西都不变。 git reset –mixed id # 就将头恢复掉已经add的暂存区也会丢失掉工作空间的代码什么的是不变的。 git reset –hard id # 那么一切就全都恢复了头变add 的暂存区消失代码什么的也恢复到以前状态。回滚到指定历史版本 git reset –hard id回滚当前仓库指向的版本 git reset –hard HEAD^^代表上一个版本的意思HEAD代表当前仓库的指向当前HEAD指向master就代表回滚到master上一次提交的版本 git reset –hard HEAD~3后面的 ~ 3代表以当前版本为基数回滚多少次。HEAD~3 代表回滚 master 前三个版本 git 查看仓库信息git remote 使用 git remote 可以查看当前仓库名称 查看提交之后文件是否做了改动git status A未修改 AM修改 Untracked未提交 modified新文件但未提交 修改缓存区内容git add、git commit -m 我们使用 git add 添加到缓存区的内容后我们在修改这个文件时它跟缓冲区内容是没有任何关系的我们使用 git commit 提交的时它只会提交缓存区内容 如果想提交第二次修改我们只需要再 git add 一次然后在使用 git commit 提交就可以了git会 自动帮我们合并提交 将改动文件添加到缓存区git add 平时我们可能写代码的时候不可能保证只改动了一个文件我们切来切去最后都不知道自己改了哪些文件为了保证所有的文件都能被准确提交我们可以使用 git add 我们确定修改的文件当 git add 后在使用 git status 查看一下状态看看是否有遗漏没有提交的文件 将所有改动文件添加到缓存区git add –all、git add . 如果你实在不确信哪些文件是改动过的你只需要使用 git add –all 这个命令会将当前目录下包括子目录下所有改动的文件提交到暂存区注意只包括改动的文件不改动的不会放到缓存区。 这个命令还会把删除的文件也提交进去 如你在本地删除了min.c 这个命令会把删除信息也记录进去然后在提交的时候把仓库里对应的 min.c 也删除掉也就是说你在本地做的删除操作会被记录提交仓库时会删除同样的文件如果不想删除文件可以使用 git add .注意后面有一个“.” 点的符号这个命令跟 git add –all 一样但是不会记录删除操作。 最后别忘了 git commit 将文件撤销回到最近一次修改的状态git checkout – file checkout切换参数通常用来切换分支仓库 注意这个恢复只能恢复到上一次提交的状态如你刚提交了这个文件到仓库随后你修改了它那么使用这个命令只会回到刚刚提交后的那个状态里不能回到你还没有提交但修改的状态中。 注意这个功能不能一直迭代恢复如你恢复到了修改前的版本你想再次回滚回滚到修改前在之前的版本是不行的。 查看单个文件可回滚版本git log filename 当我们想回滚指定文件到指定版本时需要查看该文件有多少个版本可以回滚时可以使用 git log filename 命令 即便你更新了一个文件也会生成一个新的历史版本注意历史版本里只包含了你更新的文件你刚刚只 add了min.c 文件所以新的历史版本里只有更新 min.c 文件你当前的工作其它文件没有在这个历史版本里。 查看提交历史git reflog git reflog 可以查看当前版本库的提交历史凡是对仓库版本进行迭代的都会出现在这个里面包括你回滚版本都会出现在这个历史中 删除文件git rm 如果我们使用普通的命令rm 删除文件git 状态会提示你删除了文件你只需要使用 add / commit 重新提交一次就可以了。 当然你也可以使用 git rm 删除文件但是也需要使用 git commit 提交一次 git rm 后恢复文件git rm、git reset、git checkout 此方法仅限 git rm因为 git rm 会先将文件放入缓存区,且没有使用 commit 提交的情况下 git rm d.c # 使用git rm删除一个文件 git reset # 重置所有缓存区操作 git checkout d.c # 将文件取消操作可以看到文件又恢复了 git 创建分支git branch、git checkout 使用 git checkout -b 参数来创建一个分支创建完成分支后会自动切换过去 git checkout -b dev然后我们在使用 branch 来查看当前属于哪个分支也就是查看HEAD的指向 git branchgit checkout -b 等价于 git branch dev git checkout devgit branch 如果后面跟着名字则会创建分支但不会切换 git checkout 后面如果是分支名称则切换过去 git 查看分支git branch -a 如果要查看当前所有分支可以使用git branch -a git 修改分支名称git branch -m git branch -m 分支名 新的分支名 git 切换分支git checkout 当我们想切换分支可以使用 git checkout 来切换 git checkout 的作用是检出如果是文件的话会放弃对文件的缓存区操作但是要使用 reset 重置一下变更才行。 如果是分支的话会切换过去。 git 拉取远程所有分支git fetch 当我们在本地进行开发时有时会发现有些分支看不见 可以使用 git fetch 把远程全部分支拉取下来同时也包括这些分支的仓库版本log 日志等这个操作不会进行合并。 也可以拉取指定分支的最新内容 git fetch xxxxgit查看不同分支的文件差异git diff git diff branch1 branch2 –stat //–stat参数显示两分支简单diff信息 git diff branch1 branch2 //显示两分支详细的diff信息 git diff branch1 branch2 path //显示两分支指定路径下文件的详细diff信息 git diff branch1 branch2 file_name(带路径) //显示两分支指定文件的详细diff信息注这里的分支可以是本地的也可以是远程的git diff branch1 origin/branch2 git 保存当前工作切换分支git stash Git冲突Please commit your changes or stash them before you merge git stash git pull git stash pop通过 git stash 将工作区恢复到上次提交的内容同时备份本地所做的修改之后就可以正常 git pull 了git pull 完成后执行 git stash pop 将之前本地做的修改应用到当前工作区。 git stash: 备份当前的工作区的内容从最近的一次提交中读取相关内容让工作区保证和上次提交的内容一致。同时将当前的工作区内容保存到 Git 栈中。 git stash pop: 从 Git 栈中读取最近一次保存的内容恢复工作区的相关内容。由于可能存在多个 Stash 的内容所以用栈来管理pop 会从最近的一个stash中读取内容并恢复。 git stash list: 显示 Git 栈内的所有备份可以利用这个列表来决定从那个地方恢复。 git stash clear: 清空 Git 栈。此时使用 gitg 等图形化工具会发现原来 stash 的哪些节点都消失了。 git stash show 查看栈中最新保存的 stash 和当前目录的差异。
注意 stash 是以栈的方式保存的先进后出。 一般情况下我们在修改代码时突然来了一个新的需求让我们先去做这个需求但是此时我们正在写的代码还没有完成是不可以提交的所以我们先使用 git stash 保存当前工作状态在拉取一个分支去这个分支里面干活干完活之后回到之前的分支在将工作内容恢复出来继续干活 准确来说这个命令的作用就是为了解决 git 不提交代码不能切换分支的问题。 git 合并分支git merge 当我们新建分支并做完工作之后想要把分支提交至 master只需要切换到 master 仓库并执行 git merge 分支名就可以了 如我们在分支中新建了一个 f.c 和 test.c 的文件 然后在使用 git checkout master 切换到 master 在使用 git merge dev 将其合并 这里需要说一点如果你在任何分支下创建文件没有提交到仓库那么它在所有仓库都是可见的比如你在分支 dev 中创建了一个文件没有使用 git add 和 git commit 提交此时你切换到 master这个文件依旧存在的因为你创建的文件在工作目录中你切换仓库时 git 只会更新跟仓库有关的文件无关的文件依然存放在工作区。 同时我们可以看到历史版本中有分支提交的历史 git 删除本地分支git branch –delete git branch –delete 分支名 git branch -d 分支名 # -d 是 –delete 的缩写该分支必须完全和它的上游分支 merge 完成如果没有上游分支必须要和 HEAD 完全 merge git branch -D 分支名 # -D 是 –delete –force 的缩写跳过检查 merge 状态直接 deletegit 删除远程分支git push origin –delete git push origin –delete 远程分支名【常用分支介绍】 本小节介绍常用分支以及创建合并删除的基础操作 在开发中 git 分支的重要性 当我们在开发中无论做什么操作都建议使用分支因为在团队开发中master 只有一个合作开发里任何人都可以从 master 里拉取代码拉取时 master 后创建分支分支名改为你要做的操作比如修改某某文件修改什么什么 bug单词以下划线做分割然后在提交一个版本 分支名必须简洁和标题一样提交的 commit 在简单描述一下就可以了。 如我们的 master 中有个 bug是内存泄漏 我们可以常见一个分支名为 Memory_Leak, 然后在 commit 里简单描述一下修复了哪个模块的内存泄漏不要写修复了什么什么代码什么什么问题导致的只需要简单描述一下就可以了。 一般情况下我们都是拉取master后想要修改功能或者添加功能都是创建分支在分支里修改不影响master如果修改错了代码或者误删之类的在从master上拉取一份就可以了。 1 主分支 Master 2 开发分支 Develop 主分支只用来发布重大版本日常开发应该在另一条分支上完成。我们把开发用的分支叫做 Develop Git 创建 Develop 分支的命令 git checkout -b develop master将 Develop 分支发布到Master分支的命令

切换到Master分支

git checkout master# 对 Develop 分支进行合并 git merge –no-ff develop默认情况下Git 执行快进式合并fast-farward merge会直接将 Master 分支指向 Develop 分支。 使用 –no-ff 参数后会执行正常合并在 Master 分支上生成一个新节点。为了保证版本演进的清晰我们希望采用这种做法。
3 临时性分支 3.1 功能feature分支 创建 git checkout -b feature-x develop合并到 develop 分支 git checkout develop git merge –no-ff feature-x3.2 预发布release分支 它是指发布正式版本之前即合并到 Master 分支之前我们可能需要有一个预发布的版本进行测试。 创建 git checkout -b release-1.2 develop合并到 master git checkout mastergit merge –no-ff release-1.2# 对合并生成的新节点做一个标签 git tag -a 1.2再合并到 develop 分支 git checkout develop git merge –no-ff release-1.2最后删除预发布分支 git branch -d release-1.23.3 修补 bugfixbug分支 软件正式发布以后难免会出现 bug。这时就需要创建一个分支进行 bug 修补。 创建 git checkout -b fixbug-0.1 master修补结束后合并到 master 分支 git checkout mastergit merge –no-ff fixbug-0.1git tag -a 0.1.1再合并到 develop 分支 git checkout developgit merge –no-ff fixbug-0.1最后删除修补 bug 分支 git branch -d fixbug-0.1git diff xxx.c git status . git checkout media/ git checkout framework/services/drive/ Please commit your changes or stash them before you merge git stash git pull git stash pop 【Git 版本管理 | 莫烦PYTHON】学习笔记 1 Why Git? Git 是一个分布式版本控制系统. 它的灵活性, 优越性使得它从2005年发布以来. 获得了越来越多的使用和支持. 1什么时候需要用 Git? 当你已经成为码农, 或者已经在成为码农的路上;当你觉得代码太多;当你已经开始用日期或版本号命名的代码文件的时候. 2什么文件可以被 Git 管理? 文本文件 (.txt) 等;脚本文件 (.py) 等;各种基于文本信息的文件. 3什么文件不能被 Git 管理? 图片文件 (.jpg) 等;MS word (.doc) 等. windows 系统中下载安装好 git 后我们使用 git bashgit bash 是 git 在 Windows 上为了方便使用所设置的一个 Unix 的环境. 如果你是 Windows 用户, 之后的教程你也能用这个来学习使用 git. git中文件状态转换关系如下图 图片来源https://morvanzhou.github.io/tutorials/others/git/2-1-repository/ stage the file 是 add 针对本地的一个项目如果不是从github上下载则所有文件一开始都属于untracked 状态否则都属于tracked状态。 untrackedtracked unstaged unmodifiedmodified staged
2 第一个版本库 Repository 2.1 创立版本库init 新建一个文件夹然后打开 git 把 git 的当前目录指向该文件夹eg cd Desktop/git_test/ 为了更好地使用 git, 我们同时也记录每一个施加修改的人. 这样人和修改能够对应上. 所以我们在 git 中添加用户名 user.name 和 用户 email user.email: git config –global user.name Bryant git config –global user.email bryantemail.com可以通过如下指令来查看用户信息 git config user.name结果为 Bryant git config user.email结果为 bryantemail.com 然后我们就能在这个文件夹中建立 git 的管理文件了: git init通过 ls -a 可以查看管理库的信息-a 可以查看隐藏的文件夹 手动打开文件夹看看 至此我们已经建立了一个空的管理仓库。 2.2 添加文件管理 (add) 用 git status 来查看版本库的状态: 建立一个新的文件eg 1.py用 touch哈哈参考 Linux learning notes touch 1.py现在我们能用 git status 来查看版本库的状态: git statusoutput 如下 On branch master # 在 master 分支No commits yetUntracked files:(use git add file… to include in what will be committed)1.py # 1.py 文件没有被加入版本库 (unstaged)nothing added to commit but untracked files present (use git add to track)现在 1.py 并没有被放入版本库中 (unstaged), 所以我们要使用 add 把它添加进版本库 (staged): git add 1.py然后再查看状态 git statusoutput On branch masterNo commits yetChanges to be committed:(use git rm –cached file… to unstage)new file: 1.py2.3 提交改变 (commit) 我们已经添加好了 1.py 文件, 最后一步就是提交这次的改变, 并在 -m 自定义这次改变的信息: git commit -m create 1.pyoutput [master (root-commit) 93d6b41] create 1.py1 file changed, 0 insertions(), 0 deletions(-)create mode 100644 1.py2.4 流程图 整个上述过程可以被这张 git 官网上的流程图直观地表现:untracked、unstaged、staged unmodifiedwindow 的 git bash 下显示红色 和 modifiedwindow 的 git bash 下显示绿色都为 unstaged 状态unmodified 到 modified 可通过 add 操作 3 记录修改log diff 在 git 中, 每一次提交(commit)的修改, 都会被单独的保存起来. 也可以说 git 的中的所有文件都是一次次修改累积起来的. 文件好比楼房, 每个 commit 记录 了盖楼需添加或者拿走的材料. 整个施工过程也被记录了下来. 3.1 修改记录 之前我们以 Bryant 的名义对版本库进行了一次修改, 添加了一个 1.py 的文件. 接下来我们就来查看版本库的些施工的过程. 可以看到在 Author 那已经有我的名字和 email 信息了. git log如果我们对1.py文件进行一次修改, 添加这行代码: a 1然后我们就能在 status 中git status看到修改还没被提交的信息了. 所以我们先把这次修改添加 (add) 到可被提交 (commit) 的状态, 然后再提交 (commit) 这次的修改: git add 1.py git commit -m change 1再次查看 log, 现在我们就能看到 create 1.py 和 change 1 这两条修改信息了. 而且做出这两条 commit 的 ID, 修改的 Author, 修改 Date 也被显示在上面. git log3.2 查看 unstagedno add与已 commit 的改变 如果删除一部分代码, 也会被记录上, 比如把 a 1 改成 a 2, 再添加一个 b 1. 如果想要查看这次还没 add (unstaged) 的修改部分 和上个已经 commit 的文件有何不同, 我们将使用 git diffoutput diff –git a/1.py b/1.py index 1337a53..ff7c36c 100644 — a/1.pyb/1.py-1 1,2 -a 1 a 2 b 13.3 查看 staged已 add与已commit 的改变 git add . # add 全部修改文件 git statusmodified 绿了
用 git diff –cached 来查看添加后的代码与上次 commit 提交的区别 git diff –cachedoutput diff –git a/1.py b/1.py index 1337a53..ff7c36c 100644 — a/1.pyb/1.py-1 1,2 -a 1 a 2 b 13.4 查看 staged unstaged HEAD的改变 还有种方法让我们可以查看 add 过 (staged) 和 没 add (unstaged) 的修改, 比如我们再修改一下 1.py 但不 add: a 2 b 1 c b目前 a 2 和 b 1 已被 add, c b 是新的修改, 还没被 add. git diff HEAD staged unstaged git diff unstaged git diff –cached staged # 对比三种不同 diff 形式 $ git diff HEAD # staged unstaged -1 1,3 -a 1 # 已 staged a 2 # 已 staged b 1 # 已 staged

c b # 还没 add 去 stage (unstaged)

$ git diff # unstaged -1,2 1,3 a 2 # 注: 前面没有 b 1 # 注: 前面没有

c b # 还没 add 去 stage (unstaged)

$ git diff –cached # staged -1 1,2 -a 1 # 已 staged a 2 # 已 staged b 1 # 已 staged哈哈绕来绕去的还是很麻烦的建议还是每次修改后modified 红色unstaged直接 addmodified 绿了staged然后 commit再用 git diff –cached 查看与已 commit 的区别 我们把如上的修改 add 然后 commit 方便后续实验 git add . git commit -m change 24 回到从前rest 4.1 修改已 commit 的版本 有时候我们总会忘了什么, 比如已经提交了 commit 却发现在这个 commit 中忘了附上另一个文件. 接下来我们模拟这种情况. 上节内容中, 我们最后一个 commit 是 change 2, 我们将要添加另外一个文件, 将这个修改也 commit 进 change 2. 所以我们复制 1.py 这个文件, 改名为 2.py. 并把 2.py 变成 staged, 然后使用 –amend 将这次改变合并到之前的 change 2 中 git add 2.py git commit –amend –no-edit # –no-edit: 不编辑, 直接合并到上一个 commit git log –oneline # –oneline: 每个 commit 内容显示在一行原来的 change 2 只有 1.py现在的 change 2 有 1.py 和 2.py 4.2 reset 回到 add 前绿变红 有时我们添加 add 了修改, 但是又后悔, 并想补充一些内容再 add. 这时, 我们有一种方式可以回到 add 之前. 比如在 1.py 文件中添加这一行: d 3然后 add 去 staged 再返回到 add 之前: git add 1.py git status -s # -s: status 的缩写模式绿了 git reset 1.py # 返回 add 之前 git status -s # 红了4.3 reset 回到 commit 之前staged to unstaged 在穿梭到过去的 commit 之前, 我们必须了解 git 是如何一步一步累加更改的. 我们截取网上的一些图片 http://bramus.github.io/ws2-sws-course-materials/xx.git.html 每个 commit 都有自己的 id 数字号, HEAD 是一个指针, 指引当前的状态是在哪个 commit. 最近的一次 commit 在最右边, 我们如果要回到过去, 就是让 HEAD 回到过去并 reset 此时的 HEAD 到过去的位置.

不管我们之前有没有做了一些 add 工作, 这一步让我们回到 上一次的 commit

git reset –hard HEAD git log –onelineoutput 想回到上一个 commit 法一HEAD^类推回到上上个 commit 即为 HEAD^^那回到上……上100个怎么破手动一百个^还有一种简便的形式 HEAD~1 回到前一个 git reset –hard HEAD^等价于 git reset –hard HEAD:~法二 commit id找到想要回去 commit 版本的 idgit log –oneline然后用如下指令最后一串是 id 号 git reset –hard 9c1eeb3输入 git log –oneline 看看 9c1eeb3 (HEAD - master) change 1怎么 change 2 消失了!!! 还有办法挽救消失的 change 2 吗? 我们可以查看 git reflog 里面最近做的所有 HEAD 的改动, 并选择想要挽救的 commit id: git reflog重复 reset 步骤就能回到 commit (amend): change 2 (idcb09a58) 这一步了: git reset –hard cb09a58 git log –oneline我又回来了 change 2. git log git log –help git log – ‘filename’ 查看该文件相关的commit记录 git log -p ‘filename’ 可以显示该文件每次提交的diff git show ‘commit-id’ ‘filename’ 查看某次提交中的某个文件变化 gitk –follow ‘filename’ 以图形化的界面显示文件修改列表
常用选项 表格来自 git log 查看某文件的修改历史 未完待续。。。 【附录】 git clone总是失败解决办法 git clone总是失败解决办法 git clone https://github.com/xxx.git提示下载失败, 可以尝试把 https:// 换成 git:// git clone git://github.com/xxx.git