如果你是MacOS的用户，或者与其协作的小伙伴有用MacOS的，那么大概率你会看到过Git仓库中可能出现.DS_Store这样的文件。这些文件是MacOS系统下为目录生成的，主要用来告诉MacOS下的Finder应用如何显示这个目录。 有时候，使用MacOS的开发者会不当心将这些文件提交到Git仓库中，所以我们通常都会在项目中配置.gitignore来排除这些文件。作为MacOS的开发者来说，这几乎是一个常用配置，你需要为所有的项目都做这样的配置。既然是个常规配置，那么有没有办法通过什么全局配置来一次性完成呢？ 这显然是可以完成的，我们只需要使用Git的全局.gitignore配置就可以了。 第一步：创建.gitignore文件，把要排除的文件规则编辑进去，比如 .DS_Store 第二步：通过下面命令配置需要全局排除的规则文件： git config --global core.e...

上一篇文章Git Worktree 高级使用 整体反应不错，这完全是日常开发中可以用到的奇淫技巧。微服务环境下，通常我们都会有多个 repo，高级用法好归好，但每个 repo 都按照高级用法进行配置，还是比较麻烦的，你看这不就有同学发声了嘛 说者有心，听者有意，那就写个脚本吧 Git Worktree 脚本个人不是很擅长写 bash script，磕磕绊绊写了一个 worktree.sh，完全执行上一篇文章的整个过程 #!/bin/bash -erepo=$1dir="${repo##*/}"dir="${dir%.*}"echo $dirbranch=$2defaultBranch="${branch:-main}"mkdir -p $dircd $dirgit clone --bare $repo .bareecho ...

前言上一篇文章 Git Worktree 大法真香 带大家了解了 git worktree 是如何帮助我同时在多个分支工作，并且互不影响的。但是创建 worktree 的目录位置不是在当前项目下，总感觉创建好的这些 worktree 不属于当前项目，这对于磁盘管理强迫症的我来说是十分难受的，今天就带大家了解一种高级用法来解决这个痛点 准备知识在使用高级用法之前，你需要知道一点 bare repo 知识，我们先从你熟悉的命令开始 git initgit clone https://github.com/FraserYu/amend-crash-demo.git 这两个命令就会生成一个 non-bare repo，我们通常都在这样的 repo 中进行日常工作, 你可以在这里面 add/commit/pull/push 要想生成一个 bare repo 也很简单, 只需在上面两个命令的基础...

作为程序员的我们应该都有一个感受，一旦进入某个项目，从开发，到发布，到生产，到 hotfix，到后期维护，那基本都有你的份。 正在开发某个 feature，老板突然跳出来说让你做生产上的 hotfix 更是家常便饭，面对这种情况，使用 Git 的我们通常有两种解决方案： 草草提交未完成的 feature，然后切换分支到 hotfix git stash | git stash pop 暂存工作内容，然后再切换到 hotfix 第二种方式较第一种还好很多，可是面对下面这些场景，stash 依旧不是很好的解决方案。 我们面对的场景 正在 main 分支上跑长时间的测试，切换到 hotfix 或 feature, 测试就会中断 项目非常大，频繁的切换索引，成本非常高 有几年前 release 的旧版本，设置和当前不一样，IDE restructure 适配切换也会带来很大的开销 切换分...

虽然 merging 和 rebasing 在 git 中相似时，但他们提供不同的功能。为了让你的历史尽可能的干净和完整，你应该知道以下几点。 git rebase 命令已 神奇的 Git voodoo 而闻名，初学者应该远离它，但它实际上可以让开发团队在使用时更加轻松。在本章中，我们将 把 git rebase 和与之有关联的 git merge 命令相比较 ，并在典型的 Git 工作流 中重新定位，识别其所有潜在的机会。 概述首先要明白关于 git rebase 的事情是它像 git merge 一样解决相同的问题。git rebase 和 git merge 一样都是被设计用于从一个分支获取并合并到当前分支，但是他们采取不同的工作方式。 考虑一下，当你开始在 一个专用的分支上开发新特性，与此同时另一个团队成员用新的提交来更新了 master 分支时，会发生...

记录一个昨天碰到的问题以及解决方法，希望对碰到一样问题的你有用！ 昨天升级了一下Mac OS，重启后再打开IntelliJ，突然Git就不能用了，报了下面这样的错： 开始以为是不是Git出了问题，打开终端试了一下git命令，是一切正常的，排除git客户端的损坏。 再仔细看错误原因，推测可能是路径配置问题，打开IntelliJ的菜单：Preferences...。 在左侧搜索框中直接搜索git或者直接找到Version Control菜单项，点击下属的Git功能项，此时可以看到当前的Git命令路径配置如下图： 问题就出在这里，将该路径修改为： /usr/local/bin/git 点击右侧的Test按钮，测试一下，可以看到如下图所示的结果： 完成之后，记得点击Apply和Ok按钮，然后关闭设置窗口之后，Git就可以正常使用了！

一直是 ESLint 的忠实用户，深知规范的重要性。然而，在新项目交接中，我被 Git Commit 规范逼疯了。才意识到自己的疏忽，于是便有了一探究竟的想法。 一、为什么需要规范？无规矩不成方圆，编程也一样。 如果你有一个项目，从始至终都是自己写，那么你想怎么写都可以，没有人可以干预你。可是如果在团队协作中，大家都张扬个性，那么代码将会是一团糟，好好的项目就被糟践了。不管是开发还是日后维护，都将是灾难。 这时候，有人提出了何不统一标准，大家都按照这个标准来。于是 ESLint，JSHint 等代码工具如雨后春笋般涌现，成为了项目构建的必备良品。 Git Commit 规范可能并没有那么夸张，但如果你在版本回退的时候看到一大段糟心的 Commit，恐怕会懊恼不已吧。所以，严格遵守规范，利人利己。 二、具体规则先来看看公式： <type>(<scope>): &...

由于Spring Cloud Config默认采用了Git存储，相信很多团队在使用Spring Cloud的配置中心时也会采用这样的策略。即便大家都使用了Git存储，可能还有各种不同的配置方式，本文就来介绍一下两种常用的配置策略。 第一种：多个项目公用一个Git仓库，用不同的目录区分项目 主要的配置项如下： spring.cloud.config.server.git.uri=https://github.com/dyc87112/config-repo.gitspring.cloud.config.server.git.search-paths=/{application} 这种模式下不同的项目会对应到https://github.com/dyc87112/config-repo.git仓库下的不同目录，如果项目中spring.application.nam...

在工作场合实施Git的时候，有很多种工作流程可供选择，此时反而会让你手足无措。本文罗列了企业团队最常用的一些git工作流程，包括Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow。愿以此文抛砖引玉。 在你开始阅读之前，请记住：这些流程应被视作为指导方针，而非“铁律”。我们只是想告诉你可能的做法。因此，如果有必要的话，你可以组合使用不同的流程。 （本文主要介绍Gitflow Workflow……） Vincent Driessen曾经写过一篇博文，题为“A successful Git branching model”（一个成功的Git分支模型）。Gitflow工作流程就是从这篇文章里来的。 Gitflow工作流程围绕项目发布定义了严格的分支模型。尽管它比Feature Bran...