blog:ease:git:git-basic
差别
这里会显示出您选择的修订版和当前版本之间的差别。
| 两侧同时换到之前的修订记录 前一修订版 后一修订版 | 前一修订版 | ||
|
blog:ease:git:git-basic [08:39 - 09月08日] ease [在本课程中你将会学到] |
blog:ease:git:git-basic [03:42 - 09月02日] (当前版本) |
||
|---|---|---|---|
| 行 2: | 行 2: | ||
| {{ : | {{ : | ||
| - | + | [[git-basic1|1 | |
| - | [[git-basic1|1 基本操作 ]] | + | [[git-basic2|2 git基本操作1]]\\ |
| + | [[git-basic3|3 撤销操作]]\\ | ||
| + | [[git-basic4|4 查看历史]]\\ | ||
| + | [[git-basic5|5 远程仓库]]\\ | ||
| + | [[git-basic6|6 打标签]]\\ | ||
| + | [[git-basic7|7 分支]]\\ | ||
| ===== 1. 课程前言 ===== | ===== 1. 课程前言 ===== | ||
| 行 69: | 行 73: | ||
| </ | </ | ||
| - | ===== 2. 什么是版本控制，版本控制的必要性 ===== | ||
| - | |||
| - | ==== 安全性，避免代码覆盖的灾难==== | ||
| - | 不小心从某个地方复制的时候，覆盖了最新的代码？ 或者某次 Ctrl+s 的时候，保存了错误的代码。笔者就有一次，写了600多行的代码，被一次神Ctrl+s，差点没晕倒。你经历过就知道是什么心里感受了。如果你曾经有过吃出半只小强的经历，大约能理解到笔者十分之一的感受。 | ||
| - | ====时间穿梭，多功能分支管理==== | ||
| - | 开发过程中经常可能会有一些灵感突现，然后大范围的修改代码。但是修改完了，突然发现和系统的整体架构是冲突的。这个局部的改进并不符合系统的整体结构需要。必须撤销更改，或者采用其他思路。此时你可能已经更改了若干文件，如果你想手工撤销回去，就必须记住更改了那些文件，更改了那些行，以及那些方法等。如果没有版本控制工具，这简直就是一场灾难。 然而使用git可以轻松的在代码的历史中随意“时空旅行”，并且用git来做这个事情是非常轻松的事情。 | ||
| - | |||
| - | 有时我们在开发过程中，需要尝试多种实现方案。再完成之前，并不确定那种方案更加恰当，这时使用git可以很方便的同时维护多个功能方案的分支，并且随时可以几乎无代价的切换（如果使用svn这个切换可能需要等待数分钟，这个等待是致命的，就好比你打一个字母等1秒这个字母才出现类似无法容忍） | ||
| - | ====团队分工协作，解决代码的冲突==== | ||
| - | |||
| - | 团队分工协作，经常要进行代码的整合。也有时候可能会有多个开发成员需要编辑多个相同的文件。git可以很智能的进行整合，以及对文件进行比较给出冲突的位置，或者自动进行合并工作。可以想象一下，如果没有版本控制工具，你需要对未知的多个文件；以及可能存在的相同文件，不同位置进行代码整合，这个工作该如何完成呢？（用Ctrl+c ,Ctrl+v 吗？如果只能这么干，笔者宁可放弃协作，独立开发） | ||
| - | ====掌握团队开发进度==== | ||
| - | |||
| - | git 可以记录每个开发成员的每次提交。并且提交时必须要写一个提交概要描述。因此根据提交历史可以概要的了解到每个开发成员的开发进度。以及具体功能模块或分支的开发进度。并可以针对具体的提交进行单独测或者复审。 | ||
| - | ====记录代码演进历史过程 ==== | ||
| - | |||
| - | 一个程序代码，往往需要经过多次迭代才可以做到较好的“健壮性”，“安全性”，“模块化”等程序设计的指导思想。最终的版本对于程序的用户以及后续开发都是很好的基础。但coding过程中，整个程序的架构是如何一步一步完成最终版本，体现了整个程序的演进过程，反映了设计的思路，和决策的过程。这些内容对于程序的后续开发以及新开发程序成员了解代码的开发过程是非常有帮助的。 | ||
blog/ease/git/git-basic.1536395989.txt.gz · 最后更改: 03:41 - 09月02日 (外部编辑)
