"默认git会记录文件的权限信息，如果文件的权限信息被修改，那么git也作为一个差异保存。但是我们有时候是不需要这方面的差异的（例如在Windows下使用Cygwin），这时需要关闭文件权限的检查。\ngit中可以加入忽略文件权限的配置，具体如下：\n$ git config core.filemode false $ git config \u0026ndash;list\n也可以使用以下命令查看是否生效。\ncat .git/config 还有一个小问题，在设置这个属性之前权限就混乱的话，是无法自动修复的。这时候，如果仅仅是权限混乱的话，直接git reset --hard恢复吧，git会将项目完全恢复到最近一次提交，包括权限。 "

"diff里面a表示前面那个变量，b表示第二个变量\nHEAD commit版本 Index staged版本\na、查看尚未暂存的文件更新了哪些部分，不加参数直接输入 git diff 此命令比较的是工作目录(Working tree)和暂存区域快照(index)之间的差异 也就是修改之后还没有暂存起来的变化内容。\nb、查看已经暂存起来的文件(staged)和上次提交时的快照之间(HEAD)的差异\ngit diff –cached git diff –staged 显示的是下一次commit时会提交到HEAD的内容(不带-a情况下)\nc、显示工作版本(Working tree)和HEAD的差别 git diff HEAD\nd、直接将两个分支上最新的提交做diff git diff topic master 或 git diff topic..master\ne、输出自topic和master分别开发以来，master分支上的changed。\ngit diff topic…master Changes that occurred on the master branch since when …"

"简介 brew cask 是一个用命令行管理 Mac 下应用的工具，它是基于 homebrew 的一个增强工具。\nhomebrew 可以管理 Mac 下的命令行工具，例如 imagemagick, nodejs，如下所示：\nbrew cask install qq brew cask install google-chrome brew cask install evernote 而使用上 brew cask 之后，你还可以用它来管理 Mac 下的 Gui 程序，例如 qq, chrome, evernote 等，如下所示：\nbrew cask install qq brew cask install google-chrome brew cask install evernote 安装 安装 homebrew 用以下一行命令即可安装 homebrew\nruby -e \u0026#34;$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)\u0026#34; 之后执行 brew doctor 命令可以看看 homebrew 的 …"

"这里推荐： http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html 介绍: 为什么好的提交信息如此重要\n当你随意浏览任一 git 仓库的日志，你很可能会发现其中的提交信息或多或少有点乱。举个例子，瞧一瞧我早先提交到 Spring 上的这些宝贝：\n$ git log –oneline -5 –author cbeams –before “Fri Mar 26 2009”\ne5f4b49 Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle …"

"默认情况下，使用brew install mysql 安装完mysql以后，需要手动启动mysql。为了方便以后使用，这里将mysql安装成系统服务。\nbrew info mysql 已经给了.plist文件，只需要load一下就可以，plist文件名不一定是com.mysql.mysqld.plist, 可以先到 `brew –prefix mysql` 目录看下。具体如下：\nmkdir -p ~/Library/LaunchAgents cp `brew --prefix mysql`/com.mysql.mysqld.plist ~/Library/LaunchAgents/ launchctl load -w ~/Library/LaunchAgents/com.mysql.mysqld.plist 其实 http://stackoverflow.com/questions/8014500/autostart-mysql-on-boot-from-terminal 这里有说。\ncp `brew --prefix mysql`/*mysql*.plist …"

"控制台打印：\nApplication Transport Security has blocked a cleartext HTTP (http://) resource load since it is insecure. Temporary exceptions can be configured via your app’s Info.plist file.\n在iOS9 中，苹果将原http协议改成了https协议，使用 TLS1.2 SSL加密请求数据。\n解决方法：\n在info.plist中添加 NSAppTransportSecurityNSAllowsArbitraryLoads 官方文档：\nhttps://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_13"

"1.安装类库管理工具\nCocoaPods安装和使用教程 去中心化的依赖管理器Carthage (这里没有使用这个库)\n2.安装Alamofire\nhttps://github.com/Alamofire/Alamofire\n以下为在使用Cocopods管理Alamofire类库的前后项目结构图，项目名称为CocoaPodsDemo"

"使用 git 做代码管理工具时，设置 gitignore 是必不可少的流程，一些系统或者 IDE 会在目录下生成与项目不相关的文件，而这些文件我们不期望被提交到仓库之中。理解 gitignore 的 pattern 规则十分重要。\nPattern 规则 关于 Pattern 规则，可以查看 git 的相关文档： http://git-scm.com/docs/gitignore，大致有以下几点：\n空行不匹配任何内容，所以可以作为块分隔符； # 开头表示注释，如果相匹配 #，可以在前面加一个反斜杠，即 \\#； 除非加了反斜杠，否则一连串的空格会被忽略； 如果在匹配的内容前面加上 !，则这些匹配过的部分将被移出，如果要匹配以 ! 开头的内容，需要加上反斜杠，如 \\!important.txt； 如果一个匹配 pattern 后面有一个斜杠，如 foo/，则默认会匹配所有（包含父子文件夹）中的 foo 文件夹内容，并且它不会匹配单个的文件； 如果一个匹配 pattern 不包含斜杠，如 foo，Git 会将其作为一个 shell 的查找命令匹配内容。 需要注意的**： …"

"要说表空间，Mysql的表空间管理远远说不上完善。换句话说，事实上Mysql根本没有真正意义上的表空间管理。Mysql的Innodb包含两种表空间文件模式，默认的共享表空间和每个表分离的独立表空间。只要在my.cnf里面增加innodb_file_per_table=1就可以从共享表空间切换到独立表空间。当然对于已经存在的表，则需要执行alter table MY_TABLE engine=innodb命令迁移数据。\n共享表空间方式 由于是默认的方式，就暂且理解为Mysql官方推荐的方式。相对而言所有的数据都在一个（或几个）文件中，比较利于管理，而且在操作的时候只需要open这一个（或几个）文件即可，相对来说代价很低。\n但问题是在数据达到以G为单位来计算的时候优劣逆转。一个大小惊人的文件很不利于管理，而且对于一个如此巨大的文件来说，读写它需要耗费的资源一样巨大。更加令人费解的是，MySQL竟然将索引和数据保存于同一个文件中，索引和数据之间尚存在资源争用，不利于性能的提升。你当然可以通过innodb_data_file_path的配置规划多个表空间文件，但MySQL的逻辑是“用满后增 …"

"本次，我们通过对比，明明白白的知道索引、提交频率对InnoDB表写入速度的影响，了解有哪些需要注意的。\n先直接说几个结论吧：\n1、关于索引对写入速度的影响： a、如果有自增列做主键，相对完全没索引的情况，写入速度约提升 3.11%； b、如果有自增列做主键，并且二级索引，相对完全没索引的情况，写入速度约降低 27.37%； 因此，InnoDB表最好总是有一个自增列做主键。\n2、关于提交频率对写入速度的影响（以表中只有自增列做主键的场景，一次写入数据30万行数据为例）：\na、等待全部数据写入完成后，最后再执行commit提交的效率最高； b、每10万行提交一次，相对一次性提交，约慢了1.17%； c、每1万行提交一次，相对一次性提交，约慢了3.01%； d、每1千行提交一次，相对一次性提交，约慢了23.38%； e、每100行提交一次，相对一次性提交，约慢了24.44%； f、每10行提交一次，相对一次性提交，约慢了92.78%； g、每行提交一次，相对一次性提交，约慢了546.78%，也就是慢了5倍； 因此，最好是等待所有事务结束后再批量提交，而不是每执行完一个SQL就提交一次。\n曾经 …"