Git

如果你是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 分支时,会发生...

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

在工作场合实施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...