GitHub源代码管理基本操作

最近，我进行了结对编程，并阅读了一些相关的资料，在此基础上我认为结对编程的价值，或者说它能带来的好处，是显而易见的，显著提高代码质,促进知识分享及学习,帮助团队信任及合作,形成压力和专注.偶尔有几次，我一天做了5到6个小时的结对，之后的确感觉非常疲劳.在结对编程过程中,我发现清晰地表达自己是件比较困难的事情，但我发现耐性地倾听别人的话更难，在结对的时候，倾听非常重要。我发现会因为自己没有认真倾听，过早发表自己的想法，而导致结对成为了一场无休止的争论，这样的结果非常糟糕。
在争吵后,两人结对没什么话语的交流，这样又不能。我观察下来，状态良好的结对编程，两人几乎是在不停地说话的，驾驶员一直在解释自己在干什么，领航员一直在提出问题，很多情况下两人还会把第三个人拉进去参与讨论，这样的沟通是非常高效的！
源代码管理的基本操作基本操作:
1.创建版本库
•  sudo apt-get install git 先安装git
•  先创建目录，作为仓库
•  git init 初始化仓库，可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了
•   vim readme.txt 新建一个文本文件，比如往里面添加简单的一行字符串
•   git add readme.txt 添加一个文件，比如readme.txt，如果目录里 面的所有文件都要添加，可以git add *
•   git commit-m "添加一个readme.txt文件" 将文件提交到仓库，并加上说明（这时候是版本1）
•   如果是第一次使用git，那么git commit可能报错，所以需要你配置一些个人信息
•   git config --global user.email "you@example.com" 配置邮件
•   git config --global user.name "Your Name" 配置用户名
•   必须配置，否则后面的commit、push到远程库都会失败
•   然后再次git commit -m "添加一个readme.txt文件" 才会成功
2.提交修改
•   假如此时第一次修改了readme.txt文件
•   git status 让我们时刻掌握仓库当前的状态。这时告诉我们，readme.txt被修改过了，但还没有准备提交的修改。
•   git diff readme.txt 查看对readme.txt做了什么修改
•   git add readme.txt 提交修改和提交新文件是一样，先git add
•   git status 可以再用git status查看仓库的当前状态，告诉我们，将要被提交的修改包括readme.txt
•   git commit-m "第一次修改" 然后再git commit，并添加修改的描述（这时候是版本2）
•   git status 可以再执行git status看仓库状态，因为所有的都提交了，Git告诉我们当前没有需要提交的修改，而且，工作目录是干净（working directory clean）的。
3.版本回退
•   可以像上面所说的那样不停的提交新的文件、提交对文件的修改
•   这时候第二次修改readme.txt文件
•   git add readme.txt 先git add
•   git commit -m "第二次修改" 提交第二次修改（这时候是版本3）
•   git log 显示从最近到最远的提交日志，具体显示的内容自己试一试看看
•   git log --pretty=oneline 如果嫌输出信息太多，看得眼花缭乱，试试加上--pretty=oneline参数
•   看这篇教程去理解为什么Git的版本号要这么长，Git的版本号类似：3628164fb26d48395383f8f31179f24e0882e1e0 这样的特别长的十六进制数。
•   git reset --hard HEAD^ 会回退到上一个版本，也就是从版本3回退到版本2
•   在Git中，用HEAD表示当前版本，也就是最新的提交3628164...882e1e0（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100
•   vim readme.txt 可以看到此时的readme.txt文件就是版本2时候的内容，回退成功！
•   git log 此时看到版本3的信息没有了
•   git reset --hard 3628164 通过命令行上的历史信息
•   vim readme.txt 看到的是第三版本的readme.txt文件的内容，所以又回来了
4.工作区、版本库和暂存区
工作区：就是在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区。
版本库：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
暂存区：Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的
1.  第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
2.  第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以 ，现在，git commit就是往master分支上提交更改。
可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
5.管理修改
•   vim readme.txt 编辑文件，比如添加新的一行
•   git add readme.txt 添加，但是不提交
•   vim readme.txt 再编辑文件，比如再添加一行
•   git commit -m "修改两次，添一次，提交一次" 提交
•   git status 看到的效果是：只提交了第一次的修改，第二次的修改没有提交
那怎么提交第二次修改,可以继续git add再git commit，也可以先git add第二次修改，再git commit，也就是第一次修改 -> git add -> 第二次修改 -> git add -> git commit，就相当于把两次修改合并后一块提交了。
6.撤销修改
第一种情况
•   修改了readme.txt文件，还没有git add 和git commit
•   但是在你提交之前发现这次修改有问题。既然错误发现得很及时，就可以很容易地纠正它。你可以手动把文件恢复到上一个版本的状态。
•   git checkout -- readme.txt 也可以通过命令撤销修改，这条命令的意思就是，把readme.txt文件在工作区的修改全部撤销
•   无论是文件修改后值存在于工作区还没有放到暂存区，还是已经添加到暂存区，总之这个命令就是让这个文件回到最近一次git commit或git add时的状态。
•   查看文件，内容果然复原了。git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。
第二种情况
•   修改了readme.txt文件，而且执行了git add readme.txt
•   庆幸的是你在 git commit 之前发现了这个问题
•   git status 查看一下，修改只是添加到了暂存区，还没有提交
•   git reset HEAD readme.txt 可以把暂存区的修改撤销掉，重新放回工作区。git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。
•   git status 查看一下，现在暂存区是干净的，工作区有修改
•   git checkout -- readme.txt 还记得第一种情况中如何丢弃工作区的修改吧
7.删除文件
在Git中，删除也是一个修改操作
•   添加一个新的文件 test.txt
•   git add test.txt
•   git commit test.txt -m "再次新增一个文件"
•   一般情况下，通常会在文件管理器中把没用的文件删除，或者直接rm test.txt
•   git status 这个时候，Git知道删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉哪些文件被删除了
•   现在有两个选择，一是确实从版本库中删除该文件，那就git rm test.txt，然后git commit 文件就从版本库中删除了
•   另一种情况是删除错了，因为版本库里还有，所以可以轻松地将误删除的文件恢复到最新版本git checkout -- test.txt git checkout其实使用版本库中的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原
总结
总得来说，我相信结对编程是一种非常有益的编程方式，但我反对强制他人结对，也反对快速的推行结对，结对编程会改变大多数人的思维方式，而改变人是一件急不得的事情。
最后感谢和我做结对编程的人，感谢帮助我学习成长。