虽然每天晚上带着，但是没有安装睡眠监测软件，希望 Apple 某一天出一个官方的。。。刚买的 5 代，只有某一天奇怪地一觉醒来没电了。。。除此之外，一直都很正常。。。
MacBook Pro 2012 Mid 15.6''，电池已废，离不开电源。自己动手加装 16G 内存，512G SSD，换了一个风扇，电源线断了重新买了个电源（竟然要 600 RMB)，1 米多高度掉地上一次，一个角磕进去了，导致底盖无法完全闭合，螺丝拧不正了，索性不要螺丝了。目前招灰状态，基本只在同步 iPhone 的时候才打开。最新的 Mac OS 好像问题不少，暂时还没有升级。
用了 6 年老款 MacBook Pro,换了 Surface Book 2，用了 1 年多，结果键盘底座进咖啡废了，只剩下屏幕部分。。。官方给钱都不修的。一怒之下重新配了台台式机，然后突然觉悟还是台式机性价比最高。。。不到一万块，其性能比 2W+人民币的 SB 2 高多了。 笔记本什么的，对于我来说还是作为应急产品，弄个不那么差的就行了。。。
使用 Git 这个事情，肯定比使用其它源码管理方式麻烦、复杂一些，尤其是如果想用好、用规范的话。一套流程是必不可少的。所以，首先，你要有足够的权限 /权力去推动。其他人可以提出建议、意见，但只有推动管理和规范的那些才会被考虑接纳和改进，牢骚类的直接忽略乃至驳回。如果只是平级、没有强制力，遇到抵制没辙的话，还是放弃吧。
使用 git 的目的是规范化、流程化，而不是“最简化”，因此一键 push 这样的东西不可取。git 的提交节点树是非常有价值的代码历史追踪工具，上面主要分支的每一个提交及其 message，都必须明明白白的。这样在你回溯代码问题的时候会比较清晰。
另外鉴于 git 的使用方式、方法非常灵活，因此应该需要有一个人统管 git 流程和分支管理，这个人应该就是你啦。还有对于工作的分配也要注意，不要把一个涉及同一部分代码的任务分配到多个人身上，那样会极大增加代码提交冲突的可能性。公共模块的更新，尤其是大量的更新，最好统一归到某位“高级”员工身上。
鉴于楼主的描述，依我队楼主公司的开发流程的理解和推测，可以考虑这样使用 git：
1. 所有人可以都在一个分支上工作。假设这个分支叫 dev，那么服务器上的分支就是 origin/dev,本地分支叫 dev
2. 每个人在开始工作前，首先 pull origin/dev，就是从服务器上获取最新的代码。
3. 开始自己的工作。如果要实时看自己改动的效果，那只能在自己的电脑上查看（开发不都这样么），整块功能完成之后，提交自己的代码，形成一个 commit，commit 的 message 里需要写明这次提交的代码做了什么事情，比如“完成某某功能”、“修复某某 bug”等。message 是重要信息，*一定不能随便乱写*。
4. 鉴于自己的提交完成之时，服务器上的 origin/dev 可能已经有了别人提交的代码，此时 push 代码可能会被拒绝。因此 push 的时候，通常需要分 2 步：
4.1 Fetch 然后 Rebase，Fetch 的作用是从服务器上获取最新的 origin/dev 到本地，这样你本地的 origin/dev 就和服务器同步了，同时不会影响到本地的工作区。Rebase 的作用是将步骤 3 的提交内容以最新的 origin/dev 节点为父节点“重做”，这 2 步的结果是你本地的提交的父节点现在已经是服务器上的最新节点了。如果你当前提交的节点的父节点依然是服务器上的最新节点，那么 rebase 就等于一个空操作，没有任何效果。
4.1.1 git 重做的时候可能会产生代码冲突，因为服务器上的最新节点里可能也修改了你修改的代码，此时，你需要手工解决冲突。注意，这些代码冲突产生在你本地，所以并不会影响任何其他人。冲突解决之后，你的提交就准备好 push 到服务器了。
4.2 push 本地提交。因为你做了 4.1，所以现在 push 不会有任何冲突存在，你的提交应该顺利地更新到服务器了。
如果想及时查看自己的更新的全局整合效果，那么得配一个 CI 服务器进行持续集成。CI 服务器上也有一套 git，会通过钩子或者轮询获取最新的提交，一旦有新提交被获取就会自动生成并部署一个系统版本。
以上是一个基础流程，在这个基础上可以根据其它情况进一步演化。
使用 git 的时候，无论是工作分配和开发流程，都要注意减少代码冲突的可能性，例如上述步骤 2，就为了让自己的工作始终基于最新代码之上。另外代码冲突的处理也都在本地由提交代码者处理。
你可能注意到上述流程，没有牵涉到“merge"，那是因为 merge 被 Fetch & Rebase 取代了，好处是省掉一个 merge 节点，让整个提交树非常清爽。
1. 不装盗版软件，使用 Windows 系统自带软件、广为人知的没有广告的免费（通常也开源）的软件替换，或者收费软件。
2. 各种软件只从官网下载（不要相信搜索引擎搜出的所谓“纯净版”，不要从各种“下载站”下载）
3. 你可以当这是偏见——不要使用国产软件。
三国志 4，设置新武将，把自己、你好朋友、喜欢的姑娘都加进去，然后把他们所有能力值都调整成 150 （谦虚点，别调成 254 ），所有能力都点上，然后自己做君主，带着兄弟和心爱的姑娘（们）和那些个什么三世九公，奸雄、小霸王、中山靖王之后之类的争霸天下，兵少的时候，用火计，放一个火，再改变风向，轻松烧遍整个地图，敌军再多也无济于事， 兵多的时候直接碾压敌军……
以后用笔记本在户外写代码，笔记本电池可以撑更长时间了，因为很多负载可以转移到远程了！
说一件事，当初我们公司因为用电信宽带，所以送的天翼云的虚拟机 1 年试用，于是就申请用上了，当时是当时的网管做的，我只是使用者。后来我们打算停用那个虚拟机，网管已经离职了，于是我接手，登录到管理界面后找到那个虚拟机，却发现*无法通过管理界面停用，必须联系电信经理！*于是打电话给电信经理，电信经理说这块儿她无法直接处理，必须她联系管理天翼云的人，然后我们就开始等，期间问过几次怎么还没有停用？一来二去差不多 1 个月过去了才给停了。。。幸亏我们只试用了大约半年时间，如果只差 1 周到期再试图停用，那这超期还没注销产生的费用他们主动承担么？
当然不知道现在是不是还得通过电信经理，也许已经进步了，可以在管理界面停用了也不一定。毕竟从那以后再没看过天翼云。
MacBook Pro 15'' 用了 6 年多，感觉不错。眼馋 Surface 的触摸屏，用上了 Surface Book 2，但没多久电源键就翘起一个角，虽然不影响使用，但对于强迫症患者有一定强制治疗作用。最坑的是有一回底座进水，然后底座废了，给钱官方都不修的，在被第三方坑了 5000 大洋修好之后底座用了一段时间之后又坏了，索性底座扔了，现在当个大平板用。好在买了 Surface Dock，插上大平板依然可以外接键盘和 2 个显示器，目前以半条命之身继续使用中，外出就别指望什么了，电池能撑 2 小时就不错了。电池大头都在键盘底座上。。。但是我很喜欢它的触摸屏，加上笔，给别人讲东西的时候，画画图很给力。
怎么说呢，作为 MS 粉，感觉微软的售后确实比较垃圾。虽然大概 Mac 进水了，Apple 官方也是给钱都不修？无论如何，何年何月才能有基础防水的笔记本！
Windows 系统用久了，就换 Mac，Mac 用久了换回 Windows，目前来看，如果你没有什么必须在 Windows 下运行的东西的话，建议选 Mac.
分支策略层面：
1. 不同分支应该尽量处理项目中不同区域的问题，以此降低冲突的概率。
2. 公共代码的修改应该由专人从那些分支的主干上进行修改，然后“散布”到各个子分支上去。
按 feature 进行分支本身没问题，但是如果 2 个 feature 涉及到大量公共的内容，比如同一块功能的 2 个新特性，那么应该放在一个分支上顺序实现。否则 git 也无法从根本上解决冲突的发生。
个人工作层面：
1. 尽量频繁的将自己分支的代码 rebase 到最新的父分支上，降低最终代码合并到主干时冲突的可能性，同时频繁 rebase 自己的代码，即使发生冲突，其规模也会相对较小，而且冲突的解决是在你自己的分支上，别人不受任何影响。
2. 如果涉及到公共代码的调整，一如分支策略 2 所述，要么告知负责公共代码的专人在主干上调整，然后 rebase 到你自己分支上，要么你自己在主干上调整，然后 rebase 到你自己分支。
不错，不错。从 Beta 4 阶段就在追。不知不觉都 3.0 了！可惜主要项目还是 Web Form。。。不过已经整合入了 DI 和 Entity Framework Core...
这玩意儿确实有一定的督促作用，如果我不充分利用好“摸鱼”时间，我真不知道怎么填这个日清比较好，当然楼主这个我也觉得过于繁冗。
—— 另，身处一个每天都要填“日清”，并且公司根据日清所属客户分类、条目类型、计时时长向客户收费的公司。很久前实现了工具联动，在 JIRA 里集成日清工具，开始任务的时候点一下计时，做完了就点停止。中间有断开的时间就分为多条记录，最后四舍五入到半小时单位（或者不四舍五入也行）。内部时间有单独的非 Billing 分类，基本上一天 8 小时去掉 Billing 的时间，剩下的就是公司为你额外付的钱啦。当然，公司不认为非 Billing 时间是在你身上浪费钱，只要你利用好这些时间，比如学习、甚至休息，毕竟不可能一天 8 小时都紧绷着纯工作。当然如果一周非 Billing 时间比重过高，那可能是公司问题，也可能是你的问题。
不要问虚报时间向客户多收钱的问题。我们比较自觉，而且乱填的话，客户也是要过问的。大体流程是客户提出需求，开发部门提供估时，乐观时间和悲观时间，小时为单位。如果以悲观时间计的成本客户能接受，就开工，然后实际收费按照实际日清里记录的时间。如果悲观时间的成本，客户不能接受，基本上客户会放弃或者谋求其它可能性，比如缩减、更改需求内容。
总体来说，感觉这套模式我比较喜欢，当然这套模式“诚信”是根本和基础！！
以我购买昂贵笔记本的经验。
买的时候：值
正常使用的时候：真值
修的时候：以后再不买这么贵的笔记本电脑了。
Select Language