git解决冲突只是告知程序员有冲突吗，还是git会检查冲突到底是否解决完成

有冲突，得程序员自己解决完再上传，目前git没有这么智能化，有问题自己可以修复

一般冲突的原因是两个人同时改了一个文件中的某个部分的代码，，所以啊，要分工写代码，还有在上传之前先update

git 对于大家应该都不太陌生，熟练使用git已经成为程序员的一项基本技能，尽管在工作中有诸如 Sourcetree 这样牛X的客户端工具，使得合并代码变的很方便。但找工作面试和一些需彰显个人实力的场景，仍然需要我们掌握足够多的git命令。

下边我们整理了45个日常用git合代码的经典 *** 作场景，基本覆盖了工作中的需求。

如果你用 git commit -a 提交了一次变化(changes)，而你又不确定到底这次提交了哪些内容。你就可以用下面的命令显示当前 HEAD 上的最近一次的提交(commit):

或者

如果你的提交信息( commit message )写错了且这次提交(commit)还没有推(push), 你可以通过下面的方法来修改提交信息( commit message ):

这会打开你的默认编辑器, 在这里你可以编辑信息 另一方面, 你也可以用一条命令一次完成:

如果你已经推(push)了这次提交(commit), 你可以修改这次提交(commit)然后强推( force push ), 但是不推荐这么做。

如果这只是单个提交(commit)，修改它：

如果你需要修改所有 历史 , 参考 'git filter-branch'的指南页

通过下面的方法，从一个提交(commit)里移除一个文件:

这将非常有用，当你有一个开放的补丁( open patch )，你往上面提交了一个不必要的文件，你需要强推( force push )去更新这个远程补丁。

如果你需要删除推了的提交( pushed commits )，你可以使用下面的方法。可是，这会不可逆的改变你的 历史 ，也会搞乱那些已经从该仓库拉取(pulled)了的人的 历史 。简而言之，如果你不是很确定，千万不要这么做。

如果你还没有推到远程, 把Git重置(reset)到你最后一次提交前的状态就可以了(同时保存暂存的变化):

这只能在没有推送之前有用 如果你已经推了, 唯一安全能做的是 git revert SHAofBadCommit ， 那会创建一个新的提交(commit)用于撤消前一个提交的所有变化(changes)；或者, 如果你推的这个分支是rebase-safe的 (例如：其它开发者不会从这个分支拉), 只需要使用 git push -f 。

同样的警告：不到万不得已的时候不要这么做

或者做一个 交互式rebase 删除那些你想要删除的提交(commit)里所对应的行。

注意, rebasing(见下面)和修正(amending)会用一个 新的提交(commit)代替旧的 , 所以如果之前你已经往远程仓库上推过一次修正前的提交(commit)，那你现在就必须强推( force push ) ( -f )。注意 – 总是 确保你指明一个分支!

一般来说, 要避免强推 最好是创建和推(push)一个新的提交(commit)，而不是强推一个修正后的提交。后者会使那些与该分支或该分支的子分支工作的开发者，在源 历史 中产生冲突。

如果你意外的做了 git reset --hard , 你通常能找回你的提交(commit), 因为Git对每件事都会有日志，且都会保存几天。

你将会看到一个你过去提交(commit)的列表, 和一个重置的提交。选择你想要回到的提交(commit)的SHA，再重置一次:

这样就完成了。

一般来说, 如果你想暂存一个文件的一部分, 你可这样做:

-p 简写。这会打开交互模式， 你将能够用 s 选项来分隔提交(commit)；然而, 如果这个文件是新的, 会没有这个选择， 添加一个新文件时, 这样做:

然后, 你需要用 e 选项来手动选择需要添加的行，执行 git diff --cached 将会显示哪些行暂存了哪些行只是保存在本地了。

git add 会把整个文件加入到一个提交 git add -p 允许交互式的选择你想要提交的部分

多数情况下，你应该将所有的内容变为未暂存，然后再选择你想要的内容进行commit。但假定你就是想要这么做，这里你可以创建一个临时的commit来保存你已暂存的内容，然后暂存你的未暂存的内容并进行stash。然后reset最后一个commit将原本暂存的内容变为未暂存，最后stash pop回来。

注意1: 这里使用 pop 仅仅是因为想尽可能保持幂等。注意2: 假如你不加上 --index 你会把暂存的文件标记为为存储。

如果你只是想重置源(origin)和你本地(local)之间的一些提交(commit)，你可以：

重置某个特殊的文件, 你可以用文件名做为参数:

如果你想丢弃工作拷贝中的一部分内容，而不是全部。

签出(checkout)不需要的内容，保留需要的。

另外一个方法是使用 stash ， Stash所有要保留下的内容, 重置工作拷贝, 重新应用保留的部分。

或者, stash 你不需要的部分, 然后stash drop。

这是另外一种使用 git reflog 情况，找到在这次错误拉(pull) 之前HEAD的指向。

重置分支到你所需的提交(desired commit):

完成。

先确认你没有推(push)你的内容到远程。

git status 会显示你领先(ahead)源(origin)多少个提交:

一种方法是:

在main下创建一个新分支，不切换到新分支,仍在main下:

把main分支重置到前一个提交:

HEAD^ 是 HEAD^1 的简写，你可以通过指定要设置的 HEAD 来进一步重置。

或者, 如果你不想使用 HEAD^ , 找到你想重置到的提交(commit)的hash( git log 能够完成)， 然后重置到这个hash。使用 git push 同步内容到远程。

例如, main分支想重置到的提交的hash为 a13b85e :

签出(checkout)刚才新建的分支继续工作:

假设你正在做一个原型方案(原文为working spike (see note)), 有成百的内容，每个都工作得很好。现在, 你提交到了一个分支，保存工作内容:

当你想要把它放到一个分支里 (可能是 feature , 或者 develop ), 你关心是保持整个文件的完整，你想要一个大的提交分隔成比较小。

假设你有:

我去可以通过把内容拿到你的分支里，来解决这个问题:

这会把这个文件内容从分支 solution 拿到分支 develop 里来:

然后, 正常提交。

假设你有一个 main 分支， 执行 git log , 你看到你做过两次提交:

让我们用提交hash(commit hash)标记bug ( e3851e8 for #21, 5ea5173 for #14)

首先, 我们把 main 分支重置到正确的提交( a13b85e ):

现在, 我们对 bug #21 创建一个新的分支:

接着, 我们用 _cherry-pick_ 把对 bug #21 的提交放入当前分支。这意味着我们将应用(apply)这个提交(commit)，仅仅这一个提交(commit)，直接在HEAD上面。

这时候, 这里可能会产生冲突， 参见交互式 rebasing 章 冲突节 解决冲突

再者， 我们为bug #14 创建一个新的分支, 也基于 main 分支

最后, 为 bug #14 执行 cherry-pick :

一旦你在github 上面合并(merge)了一个 pull request , 你就可以删除你fork里被合并的分支。如果你不准备继续在这个分支里工作, 删除这个分支的本地拷贝会更干净，使你不会陷入工作分支和一堆陈旧分支的混乱之中。

如果你定期推送到远程, 多数情况下应该是安全的，但有些时候还是可能删除了还没有推到远程的分支。让我们先创建一个分支和一个新的文件:

添加文件并做一次提交

现在我们切回到主(main)分支，‘不小心的’删除 my-branch 分支

在这时候你应该想起了 reflog , 一个升级版的日志，它存储了仓库(repo)里面所有动作的 历史 。

正如你所见，我们有一个来自删除分支的提交hash(commit hash)，接下来看看是否能恢复删除了的分支。

看! 我们把删除的文件找回来了。Git的 reflog 在rebasing出错的时候也是同样有用的。

删除一个远程分支:

你也可以:

删除一个本地分支:

首先, 从远程拉取(fetch) 所有分支:

假设你想要从远程的 daves 分支签出到本地的 daves

( --track 是 git checkout -b [branch] [remotename]/[branch] 的简写)

这样就得到了一个 daves 分支的本地拷贝, 任何推过(pushed)的更新，远程都能看到

你可以合并(merge)或rebase了一个错误的分支, 或者完成不了一个进行中的rebase/merge。Git 在进行危险 *** 作的时候会把原始的HEAD保存在一个叫ORIG_HEAD的变量里, 所以要把分支恢复到rebase/merge前的状态是很容易的。

不幸的是，如果你想把这些变化(changes)反应到远程分支上，你就必须得强推( force push )。是因你快进( Fast forward )了提交，改变了Git 历史 , 远程分支不会接受变化(changes)，除非强推(force push)。

这就是许多人使用 merge 工作流, 而不是 rebasing 工作流的主要原因之一， 开发者的强推(force push)会使大的团队陷入麻烦。使用时需要注意，一种安全使用 rebase 的方法是，不要把你的变化(changes)反映到远程分支上, 而是按下面的做:

假设你的工作分支将会做对于 main 的pull-request。一般情况下你不关心提交(commit)的时间戳，只想组合 所有 提交(commit) 到一个单独的里面, 然后重置(reset)重提交(recommit)。确保主(main)分支是最新的和你的变化都已经提交了, 然后:

如果你想要更多的控制, 想要保留时间戳, 你需要做交互式rebase (interactive rebase):

如果没有相对的其它分支， 你将不得不相对自己的 HEAD 进行 rebase。例如：你想组合最近的两次提交(commit), 你将相对于 HEAD~2 进行rebase， 组合最近3次提交(commit), 相对于 HEAD~3 , 等等。

在你执行了交互式 rebase的命令(interactive rebase command)后, 你将在你的编辑器里看到类似下面的内容:

所有以 # 开头的行都是注释, 不会影响 rebase

然后，你可以用任何上面命令列表的命令替换 pick , 你也可以通过删除对应的行来删除一个提交(commit)。

例如, 如果你想 单独保留最旧(first)的提交(commit),组合所有剩下的到第二个里面 , 你就应该编辑第二个提交(commit)后面的每个提交(commit) 前的单词为 f :

如果你想组合这些提交(commit) 并重命名这个提交(commit) , 你应该在第二个提交(commit)旁边添加一个 r ，或者更简单的用 s 替代 f :

你可以在接下来d出的文本提示框里重命名提交(commit)。

如果成功了, 你应该看到类似下面的内容:

--no-commit 执行合并(merge)但不自动提交, 给用户在做提交前检查和修改的机会。 no-ff 会为特性分支(feature branch)的存在过留下证据, 保持项目 历史 一致。

有时候，在将数据推向上游之前，你有几个正在进行的工作提交(commit)。这时候不希望把已经推(push)过的组合进来，因为其他人可能已经有提交(commit)引用它们了。

这会产生一次交互式的rebase(interactive rebase), 只会列出没有推(push)的提交(commit)， 在这个列表时进行reorder/fix/squash 都是安全的。

检查一个分支上的所有提交(commit)是否都已经合并(merge)到了其它分支, 你应该在这些分支的head(或任何 commits)之间做一次diff:

这会告诉你在一个分支里有而另一个分支没有的所有提交(commit), 和分支之间不共享的提交(commit)的列表。另一个做法可以是:

如果你看到的是这样:

这意味着你rebase的分支和当前分支在同一个提交(commit)上, 或者 领先(ahead) 当前分支。你可以尝试:

如果你不能成功的完成rebase, 你可能必须要解决冲突。

首先执行 git status 找出哪些文件有冲突:

在这个例子里面, READMEmd 有冲突。打开这个文件找到类似下面的内容:

你需要解决新提交的代码(示例里, 从中间 == 线到 new-commit 的地方)与 HEAD 之间不一样的地方

有时候这些合并非常复杂，你应该使用可视化的差异编辑器(visual diff editor):

在你解决完所有冲突和测试过后, git add 变化了的(changed)文件, 然后用 git rebase --continue 继续rebase。

如果在解决完所有的冲突过后，得到了与提交前一样的结果, 可以执行 git rebase --skip 。

任何时候你想结束整个rebase 过程，回来rebase前的分支状态, 你可以做:

暂存你工作目录下的所有改动

你可以使用 -u 来排除一些文件

假设你只想暂存某一个文件

假设你想暂存多个文件

这样你可以在 list 时看到它

或

首先你可以查看你的 stash 记录

然后你可以 apply 某个 stash

此处， 'n'是 stash 在栈中的位置，最上层的 stash 会是0

除此之外，也可以使用时间标记(假如你能记得的话)。

你需要手动create一个 stash commit ， 然后使用 git stash store 。

如果已经克隆了:

如果你想恢复一个已删除标签(tag), 可以按照下面的步骤: 首先, 需要找到无法访问的标签(unreachable tag):

记下这个标签(tag)的hash，然后用Git的 update-ref

这时你的标签(tag)应该已经恢复了。

如果某人在 GitHub 上给你发了一个 pull request , 但是然后他删除了他自己的原始 fork, 你将没法克隆他们的提交(commit)或使用 git am 。在这种情况下, 最好手动的查看他们的提交(commit)，并把它们拷贝到一个本地新分支，然后做提交。

做完提交后, 再修改作者，参见变更作者。然后, 应用变化, 再发起一个新的 pull request 。

在 OS X 和 Linux 下, 你的 Git的配置文件储存在 ~/gitconfig 。我在 [alias] 部分添加了一些快捷别名(和一些我容易拼写错误的)，如下:

你可能有一个仓库需要授权，这时你可以缓存用户名和密码，而不用每次推/拉(push/pull)的时候都输入，Credential helper能帮你。

你把事情搞砸了：你 重置(reset) 了一些东西, 或者你合并了错误的分支, 亦或你强推了后找不到你自己的提交(commit)了。有些时候, 你一直都做得很好, 但你想回到以前的某个状态。

这就是 git reflog 的目的， reflog 记录对分支顶端(the tip of a branch)的任何改变, 即使那个顶端没有被任何分支或标签引用。基本上, 每次HEAD的改变, 一条新的记录就会增加到 reflog 。遗憾的是，这只对本地分支起作用，且它只跟踪动作 (例如，不会跟踪一个没有被记录的文件的任何改变)。

上面的reflog展示了从main分支签出(checkout)到22 分支，然后再签回。那里，还有一个硬重置(hard reset)到一个较旧的提交。最新的动作出现在最上面以 HEAD@{0} 标识

如果事实证明你不小心回移(move back)了提交(commit), reflog 会包含你不小心回移前main上指向的提交(0254ea7)。

然后使用 git reset 就可以把main改回到之前的commit，这提供了一个在 历史 被意外更改情况下的安全网。

gitdiff对比文件的差异gitbranch列出所有分支gitlog显示提交记录分支gitbrach分支名创建分支gitcheckout分支名切换分支提交gitadd跟踪新文件或者已有文件的改动，或者用来解决冲突gitcommit把文件从stage提交到branch删除gitrm文件名不但从stage中删除，同时删除物理文件

您好，IDEA 的代码出现问题，可能涉及的原因非常多，比如语法错误、编译错误、运行时错误等等。对于无法重现的问题，估计常常就是出现了一些暂时性的情况，重启 IDE 或清除缓存等 *** 作可以解决问题。但是如果这种问题经常出现，而且没有明显的原因，我们需要对可能的因素进行排查。

可以尝试以下解决方法：

1 尝试重启 IDEA 进行代码检查和编译。

2 检查代码中是否存在语法错误、内存泄漏等问题。

3 检查代码是否与其他类或包中的代码产生冲突或不兼容。

4 检查本地环境是否出现了问题，如电脑 CPU 或内存的负荷等，也可能会影响 IDE 的运行。

5 更新 IDEA 到最新的版本。

如果这些方法不起作用，您还可以尝试在 IDEA 中使用 debug 模式，更好地跟踪应用程序在运行时发生了什么问题，并及时解决它们。

近日，一些黑客又不安分了，他们正以删除 GitHub 代码库为由，勒索受害程序员交出手中的比特币。

据 Bleeping Computer 爆料，黑客通过使用从第三方代码库管理服务泄露的帐户凭证，获得了包括 GitHub、GitLab 和 Bitbucket 等代码库的访问权限。

但是到目前为止，这些黑客还没有赚到足够的钱去星巴克买一杯咖啡。

截止到撰文时间，黑客勒索信中提到的比特币地址只收到了一笔转账，只有可怜的 000052525BTC（约为22RMB）。

黑客擦除了被攻击代码库中的代码和提交 历史 ，只留下了一个带有勒索性质的文件：

黑客“承诺”，只要受害程序员支付 01BTC（约为587美元），他们就会还原被盗的代码库。

尽管黑客可能为每封勒索信生成一个新地址，但这个地址已经在 GitHub 和 GitLab 上使用很多次了。目前，Bitcoin Abuse 上已经收到了37份关于这个地址的报告。

但到目前为止，从黑客迄今收取的赎金 （在北京，能买一份鱼香肉丝） 来看，程序员似乎并不是敲诈勒索的最佳目标。

比如这位程序员，就很牛 X 啊。

找到了，代码库并没有消失

一位名为 Stefan Gabos 的受害者在 Stack Exchange 上提出了一个解决方案，虽然他的解决方案还没有得到大多数程序员的认可，但是值得考虑。

Stefan Gabos 如何应对删库威胁并成功恢复代码？ 他是这样做的：

我当时正在做一个项目，一个私有 repo，突然间代码库中的所有提交就消失了。

我当时正在使用 SourceTree（我确定更新到了最新版本），但我仍怀疑问题所在可能就是 SourceTree，或者电脑 Windows10 系统遭到了破坏。

在我的所有代码库中，只有这一个代码库受到了影响。我更改了密码，启用了双重认证，删除了一个多年未用的访问令牌，并给 GitLab 写了一封电子邮件，希望他们能告诉我攻击者是谁、从哪里入侵了我的系统。

有人可能会说，如果他们是这样进来的，他们可能只是改变了帐户的凭证，但在互联网上搜索显示，在这些情况下 Gitlab/Github 会简单地为你恢复凭证，所以我认为这就是他们没有这样做的原因。

除了我之外，还有4个开发人员正在开发它，他们都可以完全访问被盗的代码库，因此他们的账户也有可能被入侵。

我用 BitDefender 扫描了我的电脑，但并没有发现任何问题。我没有在网上做什么见不得人的事，所以 我不认为我的电脑感染了什么病毒和木马、甚至装了一些恶意软件 。

我正在等待 GitLab 的回复，也许他们能为此提供一些线索。此外，为防止代码库被发布到其他地方，我更改了数据库、IMAP 帐户源中所有可能涉及到的密码。

出人意料，我发现代码并没有消失。

我尝试访问了一个之前提交的 hash，哇，竟然成功了。

所以代码是存在的，只是 HEAD 有点问题。

尽管我这方面的知识非常有限，但只要输入：

就能显示所有提交（commits）。

这就意味着攻击者很可能没有克隆代码库 ，而且他们通过检查源代码获取敏感数据或公开代码的几率很低；这可能不是一个有针对性的攻击，而是由一个脚本执行的随机的大规模攻击。

更令人开心的是，如果你输入：

你会看到攻击者所有的提交（commits）。

再输入：

你会看到所有“丢失”的文件。

再输入：

代码库的 origin/master 已经被修复

但当你输入：

却显示：

HEAD 已从 origin/master 中删除，正在寻找修复方法

如果代码文件保存在 本地 ，运行以下代码命令：

Bingo！代码库回来了！

、 这只是代码库存在本地时的解决方法。

因此， 现在唯一的问题是，如果你没有保存本地 repo，什么样的代码命令可以使得代码库恢复呢？ 至于攻击细节问题， 我希望 GitLab 的答案能解决我的困扰 。

在写给 ZDNet 的一封电子邮件中，GitLab 的安全主管 KathyWang 承认，Stefan Gabos 在 Stack Exchange 上提出的问题正是账户泄露的根本原因。

“我们根据 Stefan Gabos 昨天提交的内容确认了消息来源，并立即开始调查此事。我们已经确定了受影响的用户帐户，并且向他们一一通知。证据表明，丢失帐户的帐户密码以明文形式存储在相关存储库的部署（deployment）中。我们强烈建议使用密码管理工具以更安全的方式存储密码，并在可能的情况下启用双重身份验证，这两种方法都可以避免这个问题。”

微软与 Github 再背锅？

GitLab 并不是唯一受影响的网站。GitHub 和 Bitbucket 也遭到了同样的攻击和比特币勒索，多达1000个 Bitbucket 用户受到了影响。

但Bitbucket 和 GitLab 表示，他们的安全系统不存在任何问题。

Bitbucket 指出， 黑客是通过提交正确的用户名和密码获得了对用户账户的访问权限 。 “我们认为这些凭证可能是通过另一个服务泄露的，因为其他 git 托管服务正在经历类似的攻击。我们没有在上 Bitbucket 发现其他危害”。

他们怀疑是微软和 Github 的问题 （微软去年以75亿美元收购了 GitHub） 。

就在几天前，据 Micky 爆料，今年1月份微软曾轻描淡写般地回应了黑客利用 Outlook、MSN 和 Hotmail 安全漏洞盗区加密货币的事件。对此，微软表示，只有主题/标题和电子邮件地址被盗，邮件内容并未被**。

但几个月后，受害者发现其邮件内容已经被盗了，黑客通过邮件内容获取了受害者的加密货币账户并残忍地清空了账户内的加密货币。

这并不是新鲜事，删库威胁太low了

比特币性勒索诈骗已经是2018年的事了，对吧？不过，有些黑客可不这么认为。

美国堪萨斯州诺顿镇的居民正成为黑客攻击的目标。黑客威胁说，除非受害者支付比特币赎金，否则将公布一些“敏感东西”。

为此，堪萨斯州诺顿显警察局在其 Facebook 页面上还发布了一则公告，警告当地居民注意这种危险。

黑客声称通过远程控制受害者电脑的方式窃取受害者的个人数据，并拍摄了受害者观看色情片的视频。黑客还坚称，他们还有受害者当时正在看什么的屏幕截图。

如果受害者向黑客支付价值800美元的比特币，他们就承诺不会泄露受害者的视频和照片。

值得庆幸的是，这些受害者是勇敢的，没有人落入这个令人作呕的骗局。在撰写本文时，电子邮件中列出的钱包地址仍然是空的。

但去年的受害者就没这么聪明了。

在另一起比特币诈骗案中，一个黑客在几天内就赚了 17000 美元。

在这类骗局数不胜数，早在今年2月，HardFork 就发布了一份报道，报告指出，黑客通过这类骗局已经诈取了超过332万美元的钱财。

程序员，如果是你呢？

那如果是你呢？你受到了这样的威胁和勒索，你该怎么办？

正如诺顿县警方建议的那样，如果你收到这样的邮件， 请忽略它，也不要打开任何链接 ，当然也 不要将任何比特币发到邮件中列出的地址 。

在 Twitter 上，开发者社区的一些重要人物正在敦促受害者在支付任何赎金要求之前联系 GitHub、GitLab 或 Bitbucket 的支持团队，因为可能存在其他方法来恢复被删除的代码库。

值得庆幸的是，程序员对黑客的这种“小伎俩”并不感冒。

1 git gui怎么查看文件修改记录

在git中查看历史的命令主要是git log，要查看某个文件的修改历史可以这样：$ git log -- begintxt可以添加不同的选项让输出的内容或格式有所不同。

$ git log -p -- begintxt-p 选项可以输出每次提交中的diff， 但个人感觉会把输出搞得很长、很乱，不容易找到重点。个人比较喜欢的方式是：$ git log --pretty=oneline -- filename在log 命令中加入 --pretty=oneline 选项会让结果看起来清爽一些，但是只能看到ments，看不到提交的用户和日期。

2 git gui怎么查看文件修改记录

在git中查看历史的命令主要是git log，要查看某个文件的修改历史可以这样：

$ git log -- begintxt

可以添加不同的选项让输出的内容或格式有所不同。

$ git log -p -- begintxt

-p 选项可以输出每次提交中的diff， 但个人感觉会把输出搞得很长、很乱，不容易找到重点。

个人比较喜欢的方式是：

$ git log --pretty=oneline -- filename

在log 命令中加入 --pretty=oneline 选项会让结果看起来清爽一些，但是只能看到ments，看不到提交的用户和日期。

3 git 获取历史版本的几种方式

我们简单的描述一个例子：a）初始化 *** 作有两个文件file1txt和file2txt1， 初始化的时候就有这两个文件 *** 作：git initgit statusgit add git mit -m “init version”2， 在master分支上修改了file1txt，并提交 *** 作：（修改file1txt）git add file1txtgit mit -m “change file1”3， 然后新建分支banana，并切换到banana分支上 *** 作：git branch bananagit checkout banana4， 修改file1txt和file2txt，并提交。

*** 作：（修改file1txt和file2txt）git add file1txt file2txtgit mit -m “change by banana”这个时候，我们可以输入 gitk，查看一下当前的版本情况。如下图：git-0015， 然后，切换到master分支上，修改file2txt，并提交。

*** 作：git checkout master（修改file2txt）git add file2txtgit mit -m “change by master”输入gitk，查看当前版本情况，如下图：git-002b）发现问题需要查看历史版本我们现在发现当前的版本有点问题，还不能提交到版本库。1，我们需要从git mit中返回则输入：git reset --soft HEAD^解释一下，HEAD是当前分支的最新版本。

^表示父节点。当前节点的父节点，就是上一次提交的版本。

也就是标记为“change file1”的版本。问为什么不是”change by banana”这个版本呢？不同的分支哦。”

change by banana”是banana分支的最新代码，和master分支不同的。这个时候输入git status看看，是不是显示file2txt修改了没有提交呢。

2，我们需要从git add中返回再仔细查看之后，我们发现file2txt真的写错了，需要返回到git add之前的状态。输入：git reset -q file2txt这个时候，file2txt就回到了解放前了。

用git status查看一下，file2txt是”change not staged for mit”状态。3，回到没有做过的情况我们最终确定，最后一次修改的file2txt是无用的代码，我们需要废弃掉。

注意，这个 *** 作不能恢复的哦。git reset --hard这个命令，不能指定具体的文件。

是把当前的修改全部清除，恢复到最后一次提交的版本。这个时候，用gitk查看一下：git-003已经彻底回复到了“change file 1”的版本了。

4，直接回复到某个版本我们现在切换到banana分支。git checkout banana然后用gitk看一下。

可以看出，我们之前的 *** 作，对banana分支一点影响也没有。现在我们需要把banana分支回复到初始状态，但是当前的改动的代码还是需要留着。

我们可以看，init版本是当前版本的父节点的父节点。我们可以这么 *** 作：git reset --soft HEAD^^然后用gitk看一下：git-004最近的版本已经变成了init version了。

所有的改动都是add未提交状态。5，得到当前最新代码最后。

我们把file1txt和file2txt都删掉。我们需要从版本库中取得当前最新的代码。

很简单：git checkout master如果是要banana分支的最新代码，则：git checkout banana以上的 *** 作，我们知道了如何查看版本分支，和如何回复到以前的版本。

4 git gui怎么在本地建版本库

git怎么创建本地版本仓库安装git我就不用说了吧！下载地址：/msysgit/msysgit/releases/download/Git-194-preview20140815/Git-194-preview20140815exe 安装完后 点击桌面Git Bash ：命令如下$ mkdir testcms$ cd testcms$ pwd/Users/my-pc/testcmspwd命令用于显示当前目录。

在我的机器上，这个仓库位于\Users\my-pc\test\testcms。 如果你使用Windows系统，为了避免遇到各种莫名其妙的问题，请确保目录名（包括父目录）不包含中文。

第二步，通过git init命令把这个目录变成Git可以管理的仓库：$ git initInitialized empty Git repository in /Users/my-pc/testcms/git/瞬间Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），细心的开发者可以发现当前目录下多了一个git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。也不一定必须在空目录下创建Git仓库，选择一个已经有东西的目录也是可以的。

不过，不建议你使用自己正在开发的公司项目来学习Git，否则造成的一切后果概不负责。把文件添加到版本库首先这里再明确一下，所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。

版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。

不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，前面我们举的例子只是为了演示，如果要真正使用版本控制系统，就要以纯文本方式编写文件。因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。

使用Windows的童鞋要特别注意：千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“？”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。

建议你下载Notepad++代替记事本，不但功能强大，而且免费！记得把Notepad++的默认编码设置为UTF-8 without BOM即可：set-utf8-notepad++言归正传，现在我们编写一个testtxt文件，内容如下：Git is a version control systemGit is free software一定要放到testcms目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件。和把大象放到冰箱需要3步相比，把一个文件放到Git仓库只需要两步。

第一步，用命令git add告诉Git，把文件添加到仓库：$ git add testtxt执行上面的命令，没有任何显示，这就对了，Unix的哲学是“没有消息就是好消息”，说明添加成功。第二步，用命令git mit告诉Git，把文件提交到仓库：$ git mit -m "wrote a test file"[master (root-mit) cb926e7] wrote a test file 1 file changed, 2 insertions(+) create mode 100644 testtxt简单解释一下git mit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。

嫌麻烦不想输入-m "xxx"行不行？确实有办法可以这么干，但是强烈不建议你这么干，因为输入说明对自己对别人阅读都很重要。实在不想输入说明的童鞋请自行Google，我不告诉你这个参数。

git mit命令执行成功后会告诉你，1个文件被改动（我们新添加的testtxt文件），插入了两行内容（testtxt有两行内容）。为什么Git添加文件需要add,mit一共两步呢？因为mit可以一次提交很多文件，所以你可以多次add不同的文件，比如：$ git add test1txt$ git add test2txt$ git add test3txt$ git mit -m "add 3 files"现在总结创建git仓库分为三步：第一步 初始化一个Git仓库，使用git init命令。

添加文件到Git仓库：•第二步，使用命令git add ，注意，可反复多次使用，添加多个文件；•第三步，使用命令git mit，完成。这种用命令的方式感觉还是用svn好用，但是对于分布式版本控制来说git是最好的选择。

5 windows下git怎么查看提交历史

1查看Git日志：

命令：git log 默认不加参数，git日志会按照最新的日期从上往下显示 参数：-p 显示版本间的代码差异

-数字 显示部分的提交

-哈希值 显示指定的版本

2指定查找范围：

--since="5 hours" 显示最近5小时内的提交 --since="5 hours" -1 显示5小时内的最后一个提交 --before 用法和--since的用法差不多，显示的是在某个时间点之前的提交 版本1版本2 说明：版本1之后到版本2的所有提交，版本2可以用 HEAD（要注意大写）表示当前的最新版本 版本^ 回溯一个版本 注意： 在windows下要加双引号"版本^" ~N： 回溯N个版本

3查看指定版本之间的差异

git diff 版本号 说明：当前目录树和对应版本号的差异 git diff --stat 说明：统计对应改动的代码量

4撤销修改

41增补修改（只能用于针对最后一个提交）

git mit -C HEAD -a --amend

42反转提交

创建一个新的反向的提交来抵消原来的提交

git revert -n HEAD 反转当前版本库最新的提交并且缓存起来。但是不提交

43复位

git reset --soft 缓存因复位带来的差异但是不提交，也就是复位到上一个提交前的状态 git reset --hard 同时删除提交 例子：git reset --hard HEAD^ 复位到HEAD之前的那个版本

5重新改写历史记录

什么时候需要改写历史记录？

给历史记录重新排序

多个提交合并成一个提交

一个提交分解成多个提交

git rebase -i HEAD~3

本质上利用的是变基 *** 作，定位到你想变化的范围之前。然后进入编辑器去修改你想修改的部分。完成之后再回到当前的末梢。

6 怎样使用webstorm查看一个文件在git中的变动

首先，我们打开webstorm软件，然后找到项目里面的同时也在版本库中存在的文件。

打开文件后，我们点击编辑器上方菜单中"VCS"选项，在d出的菜单列表中选择“GIT”

点击后又会有一个级联菜单出现，里面的选项基本上就是git的一些常见 *** 作，我们选择“show history”选项，来查看文件的历史版本及相应改动。

我们可以看到软件下方有一个d出的界面有在这个文件名字下面有一个表格，表格的标题依次对应的是“版本号”、“日期”、“作者”、“mit信息”

然后我们随便点击一个版本所在行，就会d出一个两个版本的文件的比较界面，左边是上一个版本，右边是最新版本

两个版本相比较，以行的变动作为变动，我们可以看到绿色背静的代码是新添加的，蓝色背景的是有改动的部分。

7 windows下git怎么查看提交历史

给历史记录重新排序多个提交合并成一个提交一个提交分解成多个提交git rebase -i HEAD~3本质上利用的是变基 *** 作，定位到你想变化的范围之前指定查找范围：--since="5 hours"。

然后进入编辑器去修改你想修改的部分：版本1之后到版本2的所有提交，版本2可以用 HEAD（要注意大写）表示当前的最新版本 版本^ 回溯一个版本 注意： 在windows下要加双引号":git log 默认不加参数，git日志会按照最新的日期从上往下显示 参数； -1 显示5小时内的最后一个提交 --before 用法和--since的用法差不多：-p 显示版本间的代码差异-数字 显示部分的提交-哈希值 显示指定的版本2版本2 说明；版本^" ~N： 回溯N个版本3； 显示最近5小时内的提交 --since="5 hours"3复位git reset --soft 缓存因复位带来的差异但是不提交，也就是复位到上一个提交前的状态 git reset --hard 同时删除提交 例子：git reset --hard HEAD^ 复位到HEAD之前的那个版本5重新改写历史记录什么时候需要改写历史记录，显示的是在某个时间点之前的提交 版本1查看指定版本之间的差异git diff 版本号 说明：当前目录树和对应版本号的差异 git diff --stat 说明：统计对应改动的代码量4撤销修改41增补修改（只能用于针对最后一个提交）git mit -C HEAD -a --amend42反转提交创建一个新的反向的提交来抵消原来的提交git revert -n HEAD 反转当前版本库最新的提交并且缓存起来。但是不提交41查看Git日志：命令。

8 如何使用git gui提交代码

在windows系统客户端安装git工具。

注：如何安装git工具在此不做介绍，如需了解可网上搜索安装介绍。

在“本地文件”中添加“git文件”，用于git管理。

进入本地文件夹，右击鼠标-单击Git Init Here-生成git文件夹。

在github创建仓库用于存储管理本地文件，示例：Blog。

点击账号前的加号（Create New）--New repository，根据引导创建一个Blog仓库。

远程添加github上的Blog仓库。

1）进入本地文件夹下-右击鼠标-Git Gui-远端（remote）-Add。

2）获取github中Blog仓库的地址。

3） 在Add Remote窗口中填写名字、Location。

名字：Blog

Location：粘贴刚刚复制的Blog仓库路径

最后单击“Add”。

将本地文件内容即“已缓存的改动”，提交git管理的master分支上。

将本地文件上传到github上去。

单击Git Gui界面“上传”--“上传”窗口随意勾选一个或多个传输选项--点击“上传”--上传Blog过程中需要输入github的登录账号和密码。

在github上查看本地文件Blog项目是否上传成功。

END

注意事项

git安装

安装git程序，执行下面 *** 作：

1

$ cd ~/ssh    //检查计算机ssh密钥

2如果没有提示:No such file or directory 说明你不是第一次使用git,执行下面的 *** 作,清理原有ssh密钥

$ ls

config id_rsa id_rsapub known_hosts

$ mkdir key_backup

$ cp id_rsa key_backup

$ rm id_rsa

3获得密钥：

ssh-keygen -t rsa -C "defnngj@gmailcom"//填写email地址，然后一直“回车”ok

打开本地\ssh\id_rsapub文件。此文件里面内容为刚才生成人密钥。

4 登陆github系统。点击右上角的 Account Settings--->SSH Public keys ---> add another public keys

把你本地生成的密钥复制到里面（key文本框中）， 点击 add key 就ok了

5 接着打开git ，测试连接是否成功

$ ssh -T git@githubcom

如果提示：Hi defnngj You've successfully authenticated, but GitHub does not provide shell access 说明你连接成功了

6 设置用户信息：

61

$ git config --global username "defnngj"//给自己起个用户名

$ git config --global useremail  "defnngj@gmailcom"//填写自己的邮箱

62

在github中找到 Account Settings--->Account Admin ,找到一下信息：

Your API token is e97279836f0d415a3954c1193dba522f ---keep it secret! Changing your password will

generate a new token

$ git config --global githubuser defnngj      //github 上的用户名

$ git config --global githubtoken e97279836f0d415a3954c1193dba522f

git上传文件到服务端

1 回到github首页，点击页面右下角“New Repository”

填写项目信息：

project name: hello world

description : my first project

点击“Create Repository” ； 现在完成了一个项目在github上的创建。

2 我们需要使用git在本地创建一个相同的项目。

$ makdir ~/hello-world    //创建一个项目hello-world

$ cd ~/hello-world    //打开这个项目

$ git init    //初始化

$ touch README

$ git add README   //更新README文件

$ git commit -m 'first commit'//提交更新，并注释信息“first commit”

$ git remote add origin git@githubcom:defnngj/hello-worldgit   //连接远程github项目

$ git push -u origin master   //将本地项目更新到github项目上去

现在查看github上面的hello world 项目，是不是发现已经将本地中的README文件更新上来了。 :) 恭喜！

git GUI使用

首先在github网站上，新建一个仓库名字，需要与本地项目的根目录名字一样。

下面，我们开始使用Git Gui

下面，我们开始使用Git Gui

如果你想init一个本地的git仓库，到你的代码根目录下，右键选择Git Init Here

这时，你会发现在代码根目录下，生成了一个git的隐藏属性目录。

再选择git gui

这里有很多命令，你可以直接把你的代码add到仓库，再commit，然后再上传到github

在代码根目录，右键选择Git add all files now

再打开git gui，选择“提交“(commit)，输入提交信息，空信息是不可以提交的。

如果要上传到github，需要选择远端(remote)->Add

这相当于运行git remote add origin git@githubcom:lettoo/oriongit

这里lettoo/oriongit是我的仓库信息

Remote Add成功后，接下来就是上传了

这相当于运行git push origin master命令。

上传成功后，到githubcom网站上就可以看到你的项目代码已经上传了。

以上就是关于git解决冲突只是告知程序员有冲突吗，还是git会检查冲突到底是否解决完成全部的内容，包括:git解决冲突只是告知程序员有冲突吗，还是git会检查冲突到底是否解决完成、45 个 Git 经典 *** 作场景，专治不会合代码-、怎样使用git更新程序不影响插件数据等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！