StudyWinter的博客

之前误删了很多东西，导致一直无法将文件push到github上，最近重新配置了一下，基本好了，但是每次都得修改git下的config文件，在这里记录一下。我一般是在本地写好README.md，然后一起push。git initgit add .git commit -m "first commit"git remote add origin 仓库地址git push -u origin master基本都会在最后一步报错。解决：修改本地.git/config文件，修改结果如下：

这里不一一把内容搬过来了，贴上之前零散的帖子，再总一下。首先clone下来，再提交上去。

第一次上传项目1、 进入到本地需要往gitee上传的文件夹，右键点击选择git bash here。注意：如果此文件夹里有.git文件，请删除！2、输入命令 git init (为了给上传的文件夹添加.get 文件）3、输入命令 git remote add origin https://…get (后面的链接为gitee上的[克隆/下载] 的地址,为了给本地文件夹和gitee建立连接，记得替换，不要直接抄)4、输入命令git add . (注意命令后面有个“.”。将本地文件夹加入本地库).

git学习——第1节 git初识-优快云博客git学习——第2节 时光机穿梭-优快云博客git学习——第3节 远程仓库-优快云博客git学习——第4.1节 分支管理之创建与合并分支-优快云博客git学习——第4.2节 分支管理之解决冲突-优快云博客git学习——第4.3节 分支管理之分支管理策略-优快云博客git学习——第4.4节 分支管理之 Bug分支-优快云博客git学习——第4.5节 分支管理之Feature分支-优快云博客git学习——第4.6节 分支管理之多人协作-优快云博客gi

之后，这样，整个提交历史就成了一条直线。rebase操作前后，最终的提交内容是一致的，但是，我们本地的commit修改内容已经变化了，它们的修改不再基于。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。我们注意观察，发现Git把我们本地的提交“挪动”了位置，放到了。这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。很不幸，失败了，这说明有人先于我们推送了远程分支。先不要随意展开想象。加上刚才合并的提交，现在我们本地分支比远程分支超前3个提交。

当你从远程仓库克隆时，实际上Git自动把本地的。分支对应起来了，并且，远程仓库的默认名称是。要查看远程库的信息，用。

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的。一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。就在此时，接到上级命令，因经费不足，新功能必须取消！

有些聪明的童鞋会想了，既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在master分支上“重放”行不行？有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。同样的bug，要在dev上修复，我们只需要把。

通常，合并分支时，如果可能，Git会用模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。下面我们实战一下--no-ff方式的git merge首先，仍然创建并切换dev现在，我们切换回master准备合并dev分支，请注意--no-ff参数，表示禁用因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。合并后，我们用git log可以看到，不使用。

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。人生不如意之事十之八九，合并分支往往也不是一帆风顺的。文件存在冲突，必须手动解决冲突后再提交。Git还会自动提示我们当前。分支要超前1个提交。

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。现在有了分支，就不用怕了。

现在的情景是，你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。仓库还是空的，GitHub告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。，这是Git默认的叫法，也可以改成别的，但是。现在，我们根据GitHub的提示，在本地的。由于远程库是空的，我们第一次推送。把本地库的内容推送到远程，用。

现在，运行git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改。虽然Git告诉我们readme.txt被修改了，但如果能看看具体修改了什么内容，自然是很好的。比如你休假两周从国外回来，第一天上班时，已经记不清上次怎么修改的readme.txt，所以，需要用git diff顾名思义就是查看difference，显示的格式正是Unix通用的diff格式，可以从上面的命令输出看到，我们在第一行添加了一个单词。知道了对。

很多人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？