很久以前，发过这样一篇文章《Git全局忽略MacOS系统下的.DS_Store文件》，主要是针对MacOS用户，如何方便的在自己机器中免疫所有.DS_Store文件的误提交。如果有这个需求，且还没有搞过的读者可以通过上面这篇文章学习。
今天想要分享的是来自一个读者的私信：配置忽略.DS_Store文件是在没有提交过的前提下做的防范措施，那么如果已经把大量的.DS_Store文件提交了的话，要如何快速清理呢？这位读者还给我发了个他用的命令：
如果你是MacOS的用户，或者与其协作的小伙伴有用MacOS的，那么大概率你会看到过Git仓库中可能出现.DS_Store这样的文件。这些文件是MacOS系统下为目录生成的，主要用来告诉MacOS下的Finder应用如何显示这个目录。
有时候，使用MacOS的开发者会不当心将这些文件提交到Git仓库中，所以我们通常都会在项目中配置.gitignore来排除这些文件。作为MacOS的开发者来说，这几乎是一个常用配置，你需要为所有的项目都做这样的配置。既然是个常规配置，那么有没有办法通过什么全局配置来一次性完成呢？
这显然是可以完成的，我们只需要使用Git的全局.gitignore配置就可以了。
上一篇文章Git Worktree 高级使用 整体反应不错，这完全是日常开发中可以用到的奇淫技巧。微服务环境下，通常我们都会有多个 repo，高级用法好归好，但每个 repo 都按照高级用法进行配置，还是比较麻烦的，你看这不就有同学发声了嘛
说者有心，听者有意，那就写个脚本吧
个人不是很擅长写 bash script，磕磕绊绊写了一个 worktree.sh，完全执行上一篇文章的整个过程
上一篇文章 Git Worktree 大法真香 带大家了解了 git worktree 是如何帮助我同时在多个分支工作，并且互不影响的。但是创建 worktree 的目录位置不是在当前项目下，总感觉创建好的这些 worktree 不属于当前项目，这对于磁盘管理强迫症的我来说是十分难受的，今天就带大家了解一种高级用法来解决这个痛点
在使用高级用法之前，你需要知道一点 bare repo 知识，我们先从你熟悉的命令开始
作为程序员的我们应该都有一个感受，一旦进入某个项目，从开发，到发布，到生产，到 hotfix，到后期维护，那基本都有你的份。
正在开发某个 feature，老板突然跳出来说让你做生产上的 hotfix 更是家常便饭，面对这种情况，使用 Git 的我们通常有两种解决方案：
git stash | git stash pop 暂存工作内容，然后再切换到 hotfix第二种方式较第一种还好很多，可是面对下面这些场景，stash 依旧不是很好的解决方案。
虽然 merging 和 rebasing 在 git 中相似时，但他们提供不同的功能。为了让你的历史尽可能的干净和完整，你应该知道以下几点。
git rebase 命令已 神奇的 Git voodoo 而闻名，初学者应该远离它，但它实际上可以让开发团队在使用时更加轻松。在本章中，我们将 把 git rebase 和与之有关联的 git merge 命令相比较 ，并在典型的 Git 工作流 中重新定位，识别其所有潜在的机会。
一直是 ESLint 的忠实用户，深知规范的重要性。然而，在新项目交接中，我被 Git Commit 规范逼疯了。才意识到自己的疏忽，于是便有了一探究竟的想法。
无规矩不成方圆，编程也一样。
如果你有一个项目，从始至终都是自己写，那么你想怎么写都可以，没有人可以干预你。可是如果在团队协作中，大家都张扬个性，那么代码将会是一团糟，好好的项目就被糟践了。不管是开发还是日后维护，都将是灾难。
这时候，有人提出了何不统一标准，大家都按照这个标准来。于是 ESLint，JSHint 等代码工具如雨后春笋般涌现，成为了项目构建的必备良品。
在工作场合实施Git的时候，有很多种工作流程可供选择，此时反而会让你手足无措。本文罗列了企业团队最常用的一些git工作流程，包括Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow。愿以此文抛砖引玉。