昨天晚上，sourceforge的宕机时间刚恢复，我就打算把新的develop和master分支推上去。笔记本上的本地git库是一个改动中的，和github等上的历史结构有些不同了。结果我不小心用了强制push，于是现在github、bitbucket、sourceforge、codeplex上的git库全都被更改了。
7月8号以来pull或者fetch过develop或者master分支的用户，会受到影响。需要用Reset develop/master to this的功能reset到“KlayGE: Rendering: Fix the black screen in WinRT. (ticket #295)”这个commit，SHA-1是1217bcffd187925cdf342fb0ea11ab96。如果在原有分支上有个修改的，需要同时cherry pick到新的分支上来。
对这个push事故，我深表歉意。给大家制造麻 ...
上个月底，KlayGE已经基本完成了迁移git的任务。这个过程不是一个简单的镜像，而是在导入git的过程中，删除大文件、依赖库等，并可以通过cmake下载、解压和打补丁。对开发者来说，流程上没有什么变化，都是自动完成的。
对于第三方库，之前的做法是从原网站下载发行版代码包，从klayge.org下载补丁，用python patch打上补丁之后使用。对于有些下载速度特别慢的包，比如wpftoolkit，我也放到了klayge.org。同时，KlayGE所要的资源文件也都在klayge.org。这么以来，最近klayge.org的流量激增，本来速度就一般，现在响应更慢了。
第二个缺点是浪费。比如boost，下载包56M，解压后400M，删掉不用的文件，剩下36M我们需要的。这样对带宽和构 ...
从今天开始，KlayGE的源代码已经可以通过git来访问了。以后的更新也会都通过git进行，旧的hg访问会逐步删除。整个迁移的过程还算比较顺利的。最终经过精简的git库有90M左右，比原先需要下载576.8M的hg库小得多了，虽然精简过的hg库才16M。
新的git地址可以在这里找到。国内访问github的速度应该会高于sourceforge或者bitbucket。
转移过程中遇到的问题
上一篇文章里记录了精简hg的方法。精简过的hg可以用TortoiseHg内置的hg-git转成git库。和从hg导入git的方法和坑的实验不一样的是，现在的hg-git可以直接在命令行下推到一个bare库，不需要经过bash。所以这个过程可以直接用一个bat搞定。
尚未解决的问题
目前把新的库推到了g ...
前不久提过关于迁移到git的想法，是时候做一个详细的计划了。为此，我专门在github上启动了一个KlayGE2Git的项目，用于存放迁移过程中需要的脚本。希望对其他也有类似计划的朋友能有所帮助。
需要完成的事情
最终选择的迁移方案是方案4：单一repository，下载外部库发行版。所以在迁移的过程中，需要考虑如何减少repository大小，以及考虑迁移之后工作流需要的改变。
删除当前工作目录的大文件
第一步应该是删除当前工作目录的大文件，主要是二进制资源文件。并且需要在cmake里面加上自动下载的脚本，以便在配置工程的时候可以从klayge.org上获取需要的文件。否则后面开发的时候会有问题。这一步已经完成，目前的hg上已经没有资源文件。 ...
前不久有人问我是否把版本控制考虑转移到git的事情，其实我在2013年就写过一篇从hg导入git的方法和坑，里面给出了转移的实验，但没有具体计划。已经1年多过去了，git的工具和工作流也慢慢成熟。虽然git仍有一些基础上的缺点，比如无法进行文件改名以及轻易就可以改变历史记录，但由于有submodule和轻量的分支，再加上github的发展，从用户采纳程度来看，在git和hg的竞争中，git已经胜利。是时候再次考虑这个问题了。
需要注意的是，目前KlayGE的hg repository已经超过500M，初次pull的速度很慢，每次push的性能也受其影响。如果能在转移到git的过程中解决这个问题，这样的转移才有意义。否则只是换汤不换药。
转移到git有多种 ...
最近不少朋友提出为何不把KlayGE推到github的问题，原因是目前github只支持git，而我暂时不打算从hg切换到git。我原先觉得，既然有hg-git这样的插件，这件事情技术上应该很容易，直接转就可以了。试验了一下，发现其实还存在一些坑，必须要对付。这里拿空明大牛的salvia的repository为例子，试验从hg转到git。
第一次尝试，直接转换
安装了hg-git之后，建立一个叫做salvia-git的目录，在里面初始化一个git repository。然后在到salvia-hg的目录，直接执行hg push ../salvia-git。结果在执行了很久之后，出现
pushing to ../salvia-git
abort: The system cannot find the file specified
以失败告终。
第二次尝试，bare
在初始化git r ...git游戏杂谈
时间： 19:19:12
&&&& 阅读：29
&&&& 评论：
&&&& 收藏：0
标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&　　git作为一个知名小游戏，在被Linus开发出来后就广受好评，在程序员圈子内迅速传播，以至于现在很多程序员可以一日无饭，却不能一日无git。是什么能让各路程序员如此着迷？今天，让我们走进git，看一看领略下这款传奇游戏的精彩。
　　虽然是一款面向程序员的游戏，但git的操作其实并不复杂。总的来说，这是一款有关同步与发展的游戏，游戏模式分为团队在线，个人在线，个人本地等多种，其中又以团队在线最受欢迎，我们今天的讲解就以团队在线为主。
　　在团队在线游戏中，参与者一方面需要贡献自己的成就与进展，另一方面又要同步团队中其他人的成果，整个团队的游戏成果以一个树形进行展现，树上每一条分叉称为一个“分支”。在游戏中，你可以提交成果来推进分支，也可以创建新的分支与他人分道扬镳，甚至可以通过合并分支来获取特性。在经过无数次的分裂合并的演变过后，游戏也会演变地千奇百怪，这也是该游戏的魅力所在。
　　在git游戏中，每个玩家都拥有3个区域可供操作，线上游戏中还会有一个远程仓库提供同步存储等操作。玩家手中的游戏区域分别为：工作区，暂存区和版本库。
　　工作区是玩家日常产出成果的区域，是玩家工作的地点，工作区的内容在git中没有记录，若玩家不进行添加提交，该区域的内容就不会被保存至git。
　　暂存区可以理解为工作区和版本库中间的一个缓冲，它存储的是玩家工作区目录的索引，用来保存玩家的工作进度。玩家可以使用add操作将工作区的内容添加进暂存区。
　　版本库是最终进行成果保存以及同步的地点，玩家可以使用commit操作将暂存区的内容提交至版本库，这一操作会推进你的本地分支，并在记录上增加你所做的一切。
　　最后，远程仓库是存储所有人进展的地方，人们可以通过push操作将自己的成果推送到远程仓库，也可以用pull拉取远程仓库的信息同步到本地。
　　在游戏中提供了多种技能供玩家使用，如用于同步的add，commit， fetch， push，pull；用于查询的status, log, reflog, diff, show；用于分支操作的branch， merge，remote， reset，checkout，rebase；以及我也不知道怎么分类的balabala。下面我们来详细讲解这些技能
（此处省略一万字）
讲解完基本操作，我们来了解一下游戏中常见的一些操作。需要注意的是，当你执行切换分支，同步分支等操作之前，最好确认你的工作区和暂存区是干净的
执行任何其他操作之前看一看工作区和暂存区的内容总是好的
git status
储藏加恢复
工作区不干净的时候执行一些操作比如切换分支、同步是十分危险的，如果你不想放弃你的修改，又不想提交他们，将他们储藏起来是一个不错的选择。
git stash　　　　　　　　　　　#储藏未提交修改
其他操作　　　　　　　　　　#爱干啥干啥
git stash pop　　　　　　　　　　#把修改应用到所在的分支上
注意：stash是一个栈结构可以保存你的未同步修改，但执行pop时它会将保存的修改放入你当前所在分支，而不是你压栈的分支（如果两个分支不同的话）。另外，因为这是一个栈结构，你pop出的永远是你最后压进去的那个修改（拿到指定修改看下一条）
多次储藏花式恢复大法
上一个连招的缺陷是不能乱压乱恢复，想要恢复指定修改可以使用如下操作
git stash　　　　　　　　　　　　　　#储藏（可以有多个）git stash list　　　　　　　　　　　　& &#查看所有储藏git stash show -p stash@{0}　　　　　　#查看指定储藏git stash apply stash@{0}　　　　　　　　#应用指定储藏
此套操作用于将工作目录内容提交至本地版本库
git status　　　　　　　　　　#看有啥需要提交
git add dir/file_name　　　　　#添加到暂存区
git commit -m "xxx"　　　　　#提交到版本库，xxx为提交描述（必须写）
将B分支的修改合并到A上，保证A的工作区和暂存区是干净的。
合并完成后可以理解为A和B在内容上是两个“相同”的分支
git checkout A　　　　　　　　#切换到A分支
git merge B　　　　　　　　　#把B的修改合并到A上
注意：可能会有冲突，需要合并冲突。
merge可能有冲突，步骤：
解决冲突　　　　　　　　 　#按git提示挨个打开冲突文件编辑
git add file_name　　　　　　#把修改添加进去（有几个填几个）
git commit　　　　　　　　　#添加完提交给git
另一种合并分支（推荐本地）
将B的修改在A上复现一次。rebase和merge不同，rebase相当于将B从和A分叉开始的所有修改都在A上重新提交一次，然后合并完成后B分支会被删除。
为了你的安全考虑，不要对已经在远程仓库的分支执行rebase
git checkout A　　　　　　　　　　　　#切换到A分支
git rebase B　　　　　　　　　　　　#将B分支的内容rebase到当前分支
（如果有冲突）
解决冲突　　　　　　　　　　　　　　#修改冲突文件
git add　　　　　　　　　　　　　　#添加修改
git rebase --continue　　　　　　　　 #继续rebase
注意：rebase的冲突解决是遇到一个冲突解决一个冲突，然后继续rebase。rebase会造成B分支的删除，不要将其用在远程操作中
远程同步到本地
用于同步远程分支到你的工作区。操作前保证本地目录是干净的
git fetch　　　　　　　　　　　　　　　　#拉取所有远程分支，保存到本地origin/xxx分支（xxx为远程分支名）
git merge origin/branch_name　　　　　　#将指定远程分支修改同步到本地
如果可以保证没有冲突，并且本地分支没有新修改，可以使用
本地版本回退大法
脑抽写了一堆奇怪的代码？需求写到一半PM说这个需求又改了？没有理由劳资就是想回到以前的版本并且扔掉所有修改？
只要你的提交没push，这一切都不是问题。如果你已经push了你的修改，不要用reset，因为你的队友可能会弄死你
git log　　　　　　　　　　　　　　#查看commit记录，找到想回到的点
git reset --hard &commit&　　　　　#尖括号内为指定commit的commit id
注意：以上操作可以让你回到过去的某一次commit的状态，操作方式是将版本库HEAD指针移到你指定的commit，这会造成版本历史中被回退的部分消失，在远程操作中这很反逻辑。
--hard选项会改变你的工作区、暂存区和版本库。如果你想保留你的代码，可以使用--mix选项，这样只会改变暂存区和版本库。还有一个--soft选项，加它只会改变你的版本库。
本地版本回退大法PLUS
手贱reset了以后想恢复？
git reflog　　　　　　　　　　　　#查看修改历史，里面有你所有的操作（包括reset）
git reset --hard &commit&　　　　 #“恢复”
不用想了，你没add和commit的肯定是回不来了，且行且珍惜吧
远程版本回退大法
reset是一个很方便的回退版本的办法，但是不适用于远程。如果你的修改已经push了，这里有一个适用于远程的回退方法
git log　　　　　　　　　　　　#查看commit记录
git revert &commit&　　　　　　#撤销选中的更改
git push　　　　　　　　　　　#如果你想的话
注意：和reset不同，revert是通过提交一次撤销来进行修改，他不会导致分支回退，而是使分支向前推进一步。和reset的另一个区别是，reset是回到指定的提交，而revert只是撤销指定的那一个提交，其他提交不受影响。
待续标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&原文：https://www.cnblogs.com/Dumblidor/p/9310674.html
教程昨日排行
&&国之画&&&& &&&&&&
&& &&&&&&&&&&&&&&
鲁ICP备号-4
打开技术之扣，分享程序人生！iOS开发交流群:①群②群欢迎大家一起加入探讨问题！
「Githug」Git 游戏通关流程
他喵的这是个啥！？难道不是 GitHub 拼错了么，和 Git 什么关系？ 和游戏又有什么关系？
其实，他的元身在这里： ，这个命令行工具被设计来练习你的 Git 技能，它把平常可能遇到的一些场景都实例化，变成一个一个的关卡，一共有 55 个关卡，所以将他形象的形容为 Git 游戏。
既然是游戏，作为一个专业的游戏玩家，通关自然是我的最终目标了！！！
没什么好说的，终端运行如下命令即可，如果碰到了墙，自行搬梯子
安装游戏(盗个图)
直接输入 githug 就可以开始游戏了！开始的时候会询问是否创建文件夹，输入 y 确认创建，以后的操作将都在这个文件夹中进行。
第一关（Init）
紧接着，马上进入到了第一个关卡, 按照提示初始化这个这个 githug 文件夹为仓库。完成关卡可以通过调用 githug play 验证操作，成功则会进入下一个关卡
第二关（Config）
设置 Git 用户名和邮箱，为了不影响全局的配置，我设置的是仓库级别的。
第三关 （Add）
使用 add 命令将 README 文件添加到 staging area.
第四关 （Commit）
提交 README 文件，记得每次 commit 使用 -m 参数加上备注是个好习惯
Paste_Image.png
第五关（Clone）
克隆一个仓库，默认的文件夹名是远端的仓库名
第六关（Clone to folder）
同样是克隆一个仓库，不同的是可以指定一个文件夹名
第七关（Ignore）
忽略所有 .swp 后缀名的文件。这里使用 vim 编辑器打开 .gitignore，这个文件记录了 git 忽略文件的规则, 不会 vim 的同学可以用自己熟悉的编辑器。
使用正则(glob 模式)匹配所有的 .swp 文件，然后保存并退出
操作 .gitignore 文件
第八关（Include）
除了 lib.a 文件，其他所有的 .a 后缀名的文件都忽略。和上一关的操作一样，修改 .gitignore 文件
其中 # 开头的是注释，用 *.a 匹配所有 .a 文件，! 开头代表不要忽略
操作 .gitignore 文件
第九关（Status）
查看所有处于 untracked 状态的文件。使用 git status 查看当前仓库的状态，可以看到红色部分就是
untracked 状态的文件
第十关（Number of files committed）
其实就是查看处于 staged 状态的文件，图中黄色部分就是，所以个数就是2
第十一关（rm）
有一个文件从硬盘中删除了，但是并未从 git 仓库中删除，找到它并从 git 仓库中删除。删除也是修改的一种，提交这个修改就好了
第十二关（rm cached）
讲一个新文件从 staging area 中删除。按照要求，不应该直接从硬盘上删除这个文件，只是从 Git 中删除而已。加上
--cache 可以是文件只是从 staging area 中移除，不会真正的删除物理文件，如果要连这个物理文件也一起删除，请使用
第十三关（stash）
临时提交某个文件。这个操作在需要临时保存修改，而又不想提交的时候特别好用！而且 git 中维护了一个栈来保存，所以支持提交多次。如果需要恢复某次提交，使用
git stash apply 即可。
第十四关（Rename）
重命名文件。首先这个文件需要是已经是已追踪状态，才可以使用 git mv 命令，操作完成后自动处于 staging 状态
重命名文件
第十五关（Restructure）
移动所有 .html 文件到 src 文件夹。git mv 后面的第二个参数可以接受文件或目录，如果是目录，则文件会直接放入目录内，可以使用正则（glob模式）匹配所有 .html 文件
第十六关（Log）
找到最新的 commit 的 hash 值。使用 git log 查看历史提交记录, 找到最新的 commit 的 hash 值，记录下来用户回答问题
这里是按照倒叙排列的，最新的在最前面，commit 关键字后面跟着的就是这个 commit 的 hash 值
查看历史记录
第十七关（Tag）
为最新的 commit 打 tag。不加额外参数就是为当前 commit 记录 tag, 当然可以为特定的 commit 打
Paste_Image.png
第十八关（Push tags）
将所有本地 tag 都推送到远端。--tags 参数代表将所有的 tags 都推送到远端
第十九关（Commit amend）
某个文件在上次提交中遗漏了，在那次提交中补上这个文件。 其实，使用 git commit --amend 会进入编辑界面修改备注信息，我这里直接
:wq 保存并退出
第二十关（Commit in feature）
为提交指定一个未来的时间。
备注操作界面
第二十一关（Reset）
两个文件都被添加到了 staging area, 但是只想提交其中一个。使用 git reset 可以用仓库中的版本覆盖
staging area 的版本。
git reset 使用仓库中的版本覆盖 staging area 中的，如果 working directory 该文件没有其他修改，则
staging area 中的修改将应用到 working directory 中。反之working directory 中的版本将被保留，丢弃
staging area 中的修改。git checkout 则是使用 staging area 的中的版本覆盖 working directory。Paste_Image.png
第二十二关（Reset soft）
撤销上一次提交。
--soft 参数将上一次的修改放入 staging area--mixed 参数将上一次的修改放入 working directory--hard 参数直接将上一次的修改抛弃第二十二关
第二十三关（Checkout file）
抛弃某一次的修改，使用上次提交的版本。checkout 和 reset 的区别参照第二十一关
第二十三关
第二十四关（Remote）
查看远端仓库。其实可以不加-v参数，加这个参数只是可以将地址也一起输出(没想到下一关就是考察这个参数，平常习惯加这个参数了。。。)
第二十四关
第二十五关（remote url）
查看远端仓库的 URL
第二十五关
第二十六关（pull）
拉取远端仓库。
其实可以指定分支，格式如下
git pull origin remote : local
对应的推送的格式如下
git push origin local : remote
需要注意的两个操作的分支顺序是相反的，记忆的方法很简单，拉取是从远端到本地，所以远端在前，而推送是从本地到远端，所以本地在前。
第二十六关
第二十七关（Remote add）
添加一个远端仓库
第二十七关
第二十八关（Push）
推送本地修改到远端
Paste_Image.png
第二十九关（Diff）
查看 staging area 和 working directory 中文件的差异。
git diff: 查看 working directory 与 staging area 之间的差异
git diff --cached: 查看 repository 与 staging area 之间的差异
git diff HEAD: 查看 working directory 与 repository 之间的差异第二十九关
对应 git diff 的显示结果
第三十关（Blame）
查看某个文件的修改人。这个命令简直邪恶，锅终于有人背了！！！
git blame 列出了文件中每行的修改人是谁
文件修改记录
第三十一关（Branch）
创建一个分支
第三十一关
第三十二关（Checkout）
创建一个分支，并切换过去。其实，git checkout -b my_branch 就是创建一个分支，并切换过去，而且这种方法更方便，平常用的更多
Paste_Image.png
第三十三关（Checkout tag）
切换到某个特定的 tag
第三十三关
第三十四关（Checkout tag over branch）
切换到某个特定的分支，但是分支名和标签名重叠了
第三十四关
第三十五关（branch at）
根据一个特定的提交创建新分支
第三十五关
第三十六关（delete branch）
删除一个分支
第三十六关
第三十七关（Push branch）
将分支推送到远端仓库
Paste_Image.png
第三十八关（merge）
合并分支。为了简化分支模型，可以使用 rebase 代替，后续关卡会遇到。
第三十八关
第三十九关（fetch）
获取远端的修改，但是并不合并到当前分支。其实，git pull 就是 git fetch 和
git merge 组成的。
第三十九关
第四十关（rebase）
其实不知道怎么翻译 git rebase 这个命令。大概意思是从某个提交分化出两个分支，然后其中一个分支需要将另一个分支的修改合并过来，但是又不想在提交记录上留下两个分支合并的痕迹，只留下一个分支以前后顺序记录两边的修改。
git rebase 一个分支的所有修改在另一个分支上重新应用一遍，所以在提交记录上看，会发现一个分支的所有提交在另一个分支之前或者之后。然后删除另一个被合并的分支，保持分支简洁。
git rebase master feature 表示将 feature 上的修改在 master 上重新应用一遍
对应第一个 git log --graph -all ，--graph会用图形化将提交记录显示出来，而--all 会显示所有分支的提交记录
对应第而二个 git log --graph -all ，可以发现只保留了一个分支，看起来简洁了很多。
Paste_Image.png
在使用此命令的时候，需要非常注意的是，不要 rebase 哪些已经推送到公共库的更新，因为此操作是重新应用修改，所以公共库的更新可能已经被其他协作者所同步，如果再次 rebase 这些修改，将可能zh
第四十一关（repack）
将版本库未打包的松散对象打包
第四十一关
第四十二关（cherry pick）
应用某一个提交的修改。
第四十二关
找到我们想要的那个提交，记录下它的 hash 值ca32a6dac7b6f97975edbe19a82f68
Paste_Image.png
第四十三关 （Grep）
git grep支持各种条件搜索及正则表达式，平时用的不多，但感觉功能强大。
第四十三关
对应 git grep TODO 的结果
第四十四关（rename commit）
重命名提交。当涉及提交修改时，应该想到 git rebase -i 命令，它接受可以一个参数（提交的哈希值），它将罗列出此提交之后的所有提交，然后可以对个个提交做对应的操作。
第四十四关
重命名前的提交记录
将需要重命名的提交前的 pick 修改为 reword
选择需要重命名的提交
修改成新的备注，保存并推出
Paste_Image.png
第四十五关（squash）
合并多个提交。
第四十五关
合并前的提交记录。
Paste_Image.png
将需要合并的提交前的 pick 改成 squash 或 s。squash 代表并入前一个提交，保存并退出。
Paste_Image.png
为新的提交修改备注
Paste_Image.png
第四十六关（merge squash）
将某个分支上的所有修改都应用成一个提交。默认修改都将进入暂存区
Paste_Image.png
第四十七关
重新排列提交顺序。
第四十七关
排序前，对应第一个 git log
Paste_Image.png
在编辑界面，将 Second commit 和 Third commit 的顺序调换
Paste_Image.png
排序后，对应第二个 git log
Paste_Image.png
第四十八关
使用 git log 查看所有的提交记录，太长我就不全贴出来了，找到最开始的提交 fbbedc1f658be7496ffea467a8fb
Paste_Image.png
git bisect start master f 中，master 是有 bug 的节点，f 是没有 bug 的节点。
Paste_Image.png
第四十九关（Stage lines）
其实，提交文件的部分修改这种需求平时还是比较常见的，不过平时都是用 Source Tree 来操作的，但是看到这题之后，好像又开启了一扇大门。
Paste_Image.png
Paste_Image.png
Paste_Image.png
第五十关（Find old branch）
git reflog 可以列出所有的操作记录，所以找到之前忘记的信息并不是什么难事
对应 git reflog 的显示内容
Paste_Image.png
第五十一关（Revert）
与 reset 不同的是，revert 只会撤销当前的 commit，而之后的 commit 操作的修改还会保留，但是reset 还会将之后的所有 commit 操作的修改全部退回 staging area 或丢弃。
第五十一关
这是执行撤销操作前的记录，对应第一个git log
撤销前的记录
撤销操作会生成一个新的 commit，保存并退出即可
新的 commit
撤销之后的记录，它不破坏原有的记录，对应第二个 git log
撤销后的记录
第五十二关（Restore）
根据之前的经验，git reflog 可以查看所有的操作记录，所以只要能找到误操作之前的 commit id，一样能够恢复现场。
第五十二关
执行 git reflog 后画面如下，根据操作记录，找到你误操作的之前的 commit id
第五十三关（Conflict）
冲突处理在平常的协同工作中真是再常见不过了，需要注意的是存在冲突的文件是在 working directory 中的，在解决完冲突之后需要添加到 staging area 并提交。
第五十三关
其实冲突解决完成的图片丢失了，只能口述了。&&&&&&& HEAD 到 ======= 之间的内容代表 master 分支的修改，======= 到
&&&&&& mybranch 之间的内容代表 mybranch 分支的修改，保留 mybranch 分支的修改，删除master 分支的修改即可，当然这些特殊符号所在行也要一并删除。
第五十四关（Submodule）
submodule 是一个很方便的将一个仓库分解成多个子模块的命令，特别是项目比较大且依赖其他 Git 项目的时候，比如 Cocos2d-x。虽然好用，但是门槛也相对高点，如果维护好 submodule 还是需要好好研究一下。
第五十四关
第五十五关（Contribute）
其实到这里已经可以算是通关，如果感兴趣的话可以到 GitHub 为这个项目贡献代码。
第五十五关
其实这里的所有关卡展示的内容只是 Git 的冰山一角，Git 的魅力远不止这些，还需我们慢慢探索~
如果文章有表述错误，欢迎指正。
最后，感谢这篇文章带我入坑：
文／_Ryeeeeee（简书作者）
原文链接：http://www.jianshu.com/p/482b32716bbe
著作权归作者所有，转载请联系作者获得授权，并标注“简书作者”。
本地项目上传到自己的githug
Git学习(GitHug安装及其闯关攻略)
githug游戏--通关文档
git学习之-----githug通关记录(1-20关)
通过11个命令来精通git
githug关卡小游戏，练习git
没有更多推荐了，SourceTree用户怎么提交修改？sourceTree 切换Git登录用户（sourcetree下载,攻略问答,视频）_小黑游戏sourcetree下载
SourceTree用户怎么提交修改？sourceTree 切换Git登录用户
SourceTree用户怎么提交修改？sourceTree 切换Git登录用户，SourceTree需要修改账号，换了台电脑，sourceTree保存着原来用户的登录信息。在选项里更新用户信息后，推送代码发现，作者信息还是原来的。没有生效。
解决办法：
点击后输入vi ~/.gitconfig
按照vi的编辑方式修改即可。保存。
2.找到用户home目录，Windows即C:\Users\Administrator（当前用户）
找到.gitconfig 打开编辑保存即可。
sourcetree换某个地址账号
背景：gitlab.com通过bitbucket.org的账号授权登录，找不到密码
gitlab.com项目的输入密码报错，无赖在gitlab.com重新注册账号
通过sourcetree & https://gitlab.com/xxx/xxx.git授权无法登录，，，，在https://[新的用户名+@]gitlab.com/xxx/xxx.git:例如：https:///xxx.xxx.git就可以切换用户了,邮件不一定能支持
sourcetree推送代码 输入仓库创建者的用户名密码
如果，第一次输入错误了用户名和密码，那么以后，再输入的时候，会一直是第一次输入的用户名。
清除的方法，如上图。选中曾经输入过的用户名，点击删除即可。
SourceTree提交修改用户
之前在SourceTree提交远程服务用的是同事的账号，同事离职后账号也被注销了，然后提交不了。就需要修改账号，下面是方法：
点击&偏好设置&进入下界面：
点击&网络&，然后点击&编辑&就可以了。
免责声明：发布此文仅为传递信息之用，不代表认同其观点或证实其描述。
玩游戏就上：
SourceTree用户怎么提交修改？sourceTree 切换Git登录用户相关资讯攻略
手游排行榜