use-of-git

Git 和 SVN

SVN 是 Git 之前比较常用的版本管理系统, 但是集中式版本的弊端逐渐显露, 在很多情况下受制比较多, 具体的对比的区别自行 Google 或 Wiki.

这里对尝试学习使用的总结和学习

补充学习, 对之前学习的巩固和提升认识

待填入….

以下是之前零散的学习到的, 但是后来觉得学习的还不够, 所以有了以上的继续学习

SVN 的目录规范:

* trunk: 主干目录, 将主要的主线功能放这里
* branch: 分支, 主线之外另外的功能使用, 开发完成后, 测试稳定之后, 可以合并到主干项目中
* tags: 重大版本的备份,要开发另一个重大版本时, 要对之前一个稳定的版本备份, 当发现新版本不行, 要重头开始做的时候, 再把上次备份拿回 trunk 中
* *
* 按照项目组的不同, 在 trunk 目录下面在分几级文件, 平台划分下, 再细分, 如可以分移动组->iOS 组
* 当 trunk 完成了这个版本的制作发布后, 经理需要将这个版本备份下: 在经历连接的仓库那里点击 tags->起名->保存位置(经理需要连接的是整个微博项目的仓库, 这样才能看到 trunk 和 tags 的目录)
* 当发布稳定版本后根据市场反馈发现重大 bug, 同时2.0版本在着手进行开发, 需要开一个分支来修复 bug: 从 tags 中的稳定版本开一个分支到 branch, 然后给予指定人员权限, 那个人连接到这个分支的仓库地址.
* 当 bug 在分支修复后, 提交到仓库, 经理需要将这个修复 bug 版本的 merge 到主线中的2.0来: 先将修复好的分支 checkout 下来, 查看效果, 再从 work_copy 从 trunk 处 merge 分支修改好的项目, 再 commit
* 这时候别人在从 trunk上仓库 up 的东西就是合并了修复 bug 的版本, 这时连接分支的其他的可以断连了 
* 之后经理还要做将修复好的版本 tags 备份, 生成一个新的版本, 之后将分支删除
* 分支还可以在增加一个新功能而不影响主线开发的时候用, 开发完成后合并到主线, 发布后备份到 tags

Git

* 分布式版本控制工具, 和 SVN 不是一个量级的.比 SVN 快很多, 优点很多
* 每个终端都是一个服务器, 都有自己的一个版本仓库, 平时的 commit 操作都是 Commit 到自己的本地仓库, 等需要时再 push 到公共仓库上, 或者说是其他的终端去, 刚开始可以从其他仓库 clone 下来一个仓库, 平时可以向其他仓库 pull 一些东西下来 
* 使用工具: SourceTree, Github(针对自家 Github 平台), Xcode,

Git 的配置

* git init: 首先要在建立版本管理的地方初始化一个仓库, 然后就有了.git 文件夹, 里面装有这个仓库版本管理相关的所有东西
* git config "user.name" 用户名  配置仓库用户, 以后追踪是谁改的, 谁的操作. 或者 cat config 这个文件来修改里面的内容来配置 
* 建议配置邮箱, git 可以 办到在 Commit / push 之前发一个邮件(好像需要设置 git 的 hook)
* --globle 参数是配置全局的意思, 会让这条配置配置在整个系统, 到时整个系统中 git 的 user.name 都是这条配置的
* 要查看某个文件里的内容用 cat 文件
* add->Commit 在 git 的版本控制下不能直接扔一个文件进去就行, 要添加的还需要 add, 再 Commit 才能在版本控制中看到这个文件(add 是添加到缓冲区, commit 才是添加到版本库)
* commit: git 里必须要写注释才能提交, 而且不能为空, 后面跟提交的文件, 不写代表所有的都提交, 而且不用像 add 那样写'.'
* add: 添加文件到当前仓库, 如果添加多个文件到仓库, 直接写".", "add . "代表将当前目录的所有文件添加一遍到仓库, 单个也写.更方便, 而且.是表示所有文件这个只有 add 有, 其他操作对应这个特性是什么都不写
* *
* git config 常用配置指令:
* "user.name"   /   "user.email"
* -l : 查看配置信息
* -e : 编辑配置信息
* alias : 设置指令的别名 : 
1
git config alias.别名 原指令名/"原指令语句"
给 config 定义别名: git config alias.cfg config * 对于改动的文件, 直接提交也不行, 在 git 中, 所有修改和添加操作都要 add, add 可以可以看成是添加一个改动操作的意思, 它会把所有的改动操作添加到一个 state 暂缓区中, 在 commit 的时候一次提交到版本库里, 这样更快速, 像计算机缓存一样 * log: 可以查看文件的修改日志,日志中 commit 后跟的是版本号, 是那次提交的 sha1值, 因为是分布式, 这样可以保证版本号唯一 * log --pretty=oneline 可以打印漂亮点, 一次 commit 一行, 21d58107677a609451d960e49d2af2d733e29b43 给 car.m 添加了 car 类 403ec06a81000aa69da57495904eb24eb4625309 添加了 car.m文件 ba14c4953e895b6f6bca85d02196e7ed16cf9162 添加了多个文件 60f8f8f21f450390ce10b739bf284c8589714348 添加一个 person.m 文件 * 也可以起别名, 将一些配置设置指令配成一个指令, 来打印更好的日志格式:
1
git cfg --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an> %Creset' --abbrev-commit"
这样全局的 git 的 log 都是这样的, 不用去重复配置

git 的版本回退

* git 支持无限次后悔: RESET
* reset --hard HEAD^  : 回到上一个版本, ^^:上上个版本, 还可以~1, 上一个, ~3, 上上上个版本, hard  指示强转回退, 可以起别名
* 可以在不同的版本号间跳转: reset --hard 版本号
* 如果不知道版本号, 可以用git reflog 查看之前的所有操作, 找到最后一次提交的操作回退
* 写了一堆东西不想要了, 可以回退到当前最新版本号就可以了 HEAD

移除文件:

* remove: rm 文件名, 这个 rm 操作一样是放操作进缓存区, 可以回退到 HEAD 来撤销 rm 操作, 如果 Commit 了, 就回退到上一版本, 再要回来就回退到最新版本号

缓冲区

* 在对文件做了改变时, 要在 Commit 前将这些改点放到缓冲区, 提交时会把缓冲区的提交到版本库, 没有在缓冲区的提交不上去, 版本库对这些改变就没有记录了
* state : 查看某个文件(或全部 )的状态, 没有进缓冲区的 change 会提示出来, 进缓冲区待提交的也会标出来, 颜色不一样

* diff: 查看某个文件的修改状态, git diff, 放进缓存区后就看不到修改的状态了
* config -e: 进入 vim 编辑配置文件

工作原理:

* 工作原理:
    * 工作区(Working Directory): 即平时我们开发所要动到的文件, 操作到的目录, 即非.git 的里那些而是我们自己建的东西
    * 版本仓库(Repository): 即 git 给我们做版本控制的地方, 即.git 目录下的东西
        > 暂缓区(stage): 当文件做了修改时 add 到的缓冲区, 
        > 分支(master): git 自动创建的第一个分支, 默认一开始就在这个分支下进行版本控制
        > HEAD 指针: 用于指向当前分支, git branch. 查看当前分支

当有改变时, 暂缓区是空的, 工作区的状态改变了, 要先 add. add 到版本库的stage 里, stage 里就有了当前工作区新做的改变, 在 commit 提交到HEAD 所指的分支版本库, commit 后暂缓区会清空. 而且工作区和分支东西一致后会显示 clean, 干净的.
比如有新添加文件时, status 指令会提示Untracked files:, 证明这个文件没有在版本控制的追踪下,分支中没有这个文件,是新建的, -> add 添加到暂缓区,Untracked files:修改已经进入暂缓区, 有待 commit 到分支中 ->  1 file changed,成功在分支中添加了一个文件, 再差 status 会是working directory clean, 和分支追踪的文件没有什么异同
当文件改动时,Changes not staged for commit: 文件的改动没有放暂缓区中待 commit,  -> add. st 变为待提交, ->commit -> 成功

远程仓库

* 自己搭建的话比较费时费力, 因为一般是搭建在 Linux 上的, 
* 我们一般用公开的别人搭好的公共托管仓库, github, oschina,  coding
* Github: -> 右上角有个创建仓库, 
              -> readme 一定要选, 可以介绍你这个项目是做什么用的, 还有项目的一些描述, 使用方法等
              -> .gitignore 可以忽略掉不用提交的文件, 可以在这个文件里面编写匹配哪些文件是不需要提交的 
              -> 右边有个 HTTPS clone URL , 就是项目仓库的路径, 这样就可以给别人下载到自己的仓库
              -> 在当前 .git 所在的目录下, 使用 'git remote add origin {这里是你的在 git 托管平台上创建项目的地址}' 来添加当前 git 仓库锁指向的远程仓库, 这样之后我们 pull 和 push 就会对这个仓库进行读写, 建议先 pull 项目下来和当前本地的 merge 一下(对于 git@ 的地址来说可以, HTTPS 的地址只能 pull 操作不能 push, 因为缺少 sshkey 的认证), 或者可以先把网上的仓库 clone 到当前目录->git clone URL 再把项目文件夹放进这个目录, 这时工作区就可以用之前的操作, add. commit 到本地仓库, 
              -> 这时只是在本地分支有这些操作, 还需要 push 到远程仓库去,
              -> git push  ----然后首次会要求输入用户名密码, 就是 github 的用户名密码
* 想要在自己电脑上 push 项目还需要一些设置, 这个在一开始就要配置了!
    -> git 远程是用 ssh 连接的, 需要把自己电脑上的 ssh keyes 添加到 github 的设置上, 表示只有这个 ssh keyes 所有者才能 push 代码, 只有配置了 key 在 github 上的电脑才能传东西, 以后参与开发的组员也是需要配置 key 到这个项目的 github 上
    -> 获取 sshkey: 在电脑上用终端在~/.ssh 里创建公钥私钥对, 
    ->命令: ssh-keygen -t rsa -C "你的邮箱地址" -> 然后一直敲回车 ->然后会在~/.ssh 目录下生成 ssh key 密钥对
    -> id_rsa : 私钥, 不可泄露
    -> id_rsa.pub : 公钥, 可以公开(将这个文件的内容粘贴到 Github 上)
    -> 利用 cat 可以查看文件内容
    -> 将pub 公钥粘贴到 gihub 上的 key 框中, add key.
每次增加新东西, commit 在本地仓库了想一次性的传到服务器的话, 用 push, 
其他组员第一次从服务器拿东西下来是用 clone拿到整个项目, 
之后每次从服务器更新东西都是 pull, 拉下新的变动的东西, 
用 github 客户端也可以办到以上和远程仓库同步
现在 github 也可以用 https


使用 oschina 和 coding 的好处是本地化更好一点, 私有项目免费1000个, 速度更快, 
创建仓库的过程都差不多

GitHub 有个 pullRequest 可以 fork 别人的项目, 燃火做一些改进后 pull Request 给作者, 看它会不会合并你的请求

热评文章