共 23 篇相关文章
很多团队在拆分大型 Git 仓库时，都会遇到 submodule 和 subtree 的选择问题。本文围绕两种方案的实际维护体验展开分析，而不是只停留在命令层面对比。 作者认为，submodule 更符合“仓库独立治理”的设计目标，适合需要清晰边界、独立版本管理和长期维护的大型项目；而 subtree 虽然使用门槛更低、clone 更方便，但容易造成代码冗余和仓库持续膨胀。 文章比较有价值的地方在于，它没有单纯强调“哪种更简单”，而是从架构治理、团队协作和长期维护成本角度讨论问题，适合已经进入中大型工程阶段的团队参考。 如果你正在做 monorepo 拆分、多仓库治理，或者维护复杂依赖关系，这篇文章值得一读。
最近要把 Git 仓库迁移，看有些同学迁移中不太顺利，自己研究总结了下，分享给大家，本文将向大家介绍迁移 Git 仓库的的方法。
有时候我们会后悔，有时候我们会想回到过去，有时候我们想改变历史，然而在我们这个世界，目前来看是无法回到过去改变历史的 但在git的世界里，一切皆有可能，我们可以在多维空间里任意切换，随意改变一个宇宙的时间线，只要我们愿意，git的分支就是这么神奇 然而很多时候你以为你改变了历史，不为人知，那个宇宙并没有消失，而是遗失在了git的世界里，有能力的人便能找到 彼此分开的世界也能随时交叉合并，世界就这样开开合合，偶会需要解决合并冲突 git中的分支非常的轻量，其实就是一个文件，里面记录了分支所指向的commit id，下图中有两个分支分别是master和test，他们都指向了A2这个提交，HEAD是一个特殊的指针，他永远指向你当前所在的位置；有时候你可能不在某一个分支上，不要惊慌，你随时有权利去你想去的分支，git赋予了你新建，切换分支的能力。
Github 是一个存放着世界上最棒的一些软件项目的宝藏，这些软件项目由全世界的开发者无私贡献。这个看似简单，实则非常强大的平台因为大大帮助了那些对开发大规模软件感兴趣的开发者而被开源社区所称道。 这篇向导是对于安装和使用 GitHub 的的一个快速说明，本文还将涉及诸如创建本地仓库，如何链接这个本地仓库到包含你的项目的远程仓库（这样每个人都能看到你的项目了），以及如何提交改变并最终推送所有的本地内容到 Github。 请注意这篇向导假设你对 Git 术语有基本的了解，如推送、拉取请求（PR）、提交、仓库等等。并且希望你在 GitHub 上已注册成功并记下了你的 GitHub 用户名。
Git是一个分布式版本控制软件，原来是linux内核开发者Linus Torvalds为了更好地管理linux内核开发而创立的。发展至今，Git已经成为了一个相当好用的版本管理工具。相比于SVN，如果想要保存一些微小的修改也必须得提交服务器保存才可以，这样使服务器的版本号过多，而Git解决了这个问题，一些小的修改只在本地提交即可，只需最后修改完成后再提交服务器。正是由于这样的便捷性，现在越来越多的社区项目都开始使用Git来取代SVN之类较为传统的版本管理工具进行开发。
在mac上，beyond compare默认没有安装命令行，需要通过如下方式安装命令行....
对很多开发者，尤其是手握几台甚至几十台机器的同学而言，登录到远程机器处理事务应该是家常便饭。如果你也是其中一员，悄悄问一句，你平时是如何记住一堆帐号、机器地址以及一些附加登录选项的呢？ 撰写本文之前，我已经踩坑三小时，花了三个小时，摸索出来这么些东西，感觉以后妈妈再也不用担心我的 Git/SSH 的配置问题了。 最主要的手段依然是通过 ssh -vT 查看 SSH 交互过程中出现了什么障碍，debug 信息还是很有考究价值的！
当我在使用git的时候，有三个东西的出现，一度让我非常困扰，就如题所述，staging，index，和cache。 比如，当我阅读git官网提供的电子书《Pro Git》的时候，最初一章里，就提到，文件在git里面，有三种状态，working copy，staging area，和 in repository。而在读一些man pages的时候，比如git-reset命令，又会看到index，这非常让人困扰。而git-rm 指令又有一个参数叫 –cached，其作用是”unstage and remove paths only from the index”，更加奇怪了，同时提到了stage和index，而参数名竟然是cached！！！
首先我表明一个根本的立场，我个人更喜欢用git，但是，这仅仅是一个个人偏好。当我们需要将一种技术方案带给整个团队的时候，并不是由我们的个人偏好作为主要决定因素，而应该充分去权衡利弊，选择对团队，对公司更有效率的方案。抛开个人立场，理性评估利弊，可能才是我认可的一个资深程序员，或者一个架构师的本分。 我所在的团队，现在选用的技术方案是git作为全公司的版本控制系统，我们一共有差不多20个程序员，使用五种以上的程序设计语言，研发维护四个左右的项目，属于小型创业公司中，研发规模中等偏上的企业。使用git作为版本控制系统，在我加入公司之前，已经是既成事实了，在我听说这一点的时候，我非常高兴，因为我说过，我喜欢git。
今天追了个几年前留下来的坑, 在 git 里追溯修改过程坑死个爹, 具体方法估计没多久又会忘, 还是记下来以后有的参考
Git确实比svn好用，就是稍微不容易理解。 git分本地库和远程库，修改的工作代码要先提交到本地库，然后再提交到远程库。这个是刚接触的人比较困惑的地方，还有分支来困扰，所以了解了解工作代码、本地库和远程库后，创建、切换、合并、删除分支也是重点要了解的。
转眼间加入git的阵营已经快两年了，结识git，缘起github，2年前在寻找代码托管网站，当时还是用svn，起初使用google code，可是google的服务虽好，在天朝你懂得，后来发现了github，多亏了蒋鑫老师的《GotGitHub》将我带入github的大门，如果你是个github新手，那我强烈建议你阅读这篇文章，里面讲了很多东西。
Git submodule 的繁琐似乎是世人皆知了， 所以我用 subtree 来解决上面的包含关系。即： 在 Gregarius 中以 subtree 的方式管理 MagpieRSS， 然后在 MagpieRSS 中以 subtree 的方式管理 Snoopy。 问题的产生 subtree 处理多层包含是没有问题的，因为包含进项目之后， 别人根本看不出这是一个 subtree， 所以它本质上还只是管理本地 repo 的一种方法。 使用 Git subtree 新建或更新子项目的时候，可以选用 --squash 参数， 它的作用就是把 subtree 子项目的更新记录进行合并，再合并到主项目中。
前一段时间分享了一篇《更好的 git log》简要介绍怎么美化 git log 命令，其中提到了 alias命令，今天再继续谈谈 git相关， 看看如何通过配置自己的 git config 让自己的 git 用起来更顺手。
Git常用命令备忘
Git 本身并没有硬性限制注释的格式，不过，对于多人参与的项目来说， 好的注释风格更加有利于团队合作。 即使是自己用，也应当坚持实用好的注释风格， 一来是对自己的工作历史负责，二来得以养成好的注释习惯。 虽然这里标题说的是 Git，其他源代码控制系统也可以参考的。
我在半年前开始在公司内推广使用git flow，控制版本发布流程，到目前为止效果令人满意。但是实际使用过程中有一些小小的意外流程，完全照搬git flow的模型不太容易处理好。好在git本身就很灵活，碰到问题基本上都有办法绕过去。下面是我总结的一些特例情况下的处理办法。
这篇主要是记录我在 Windows 平台安装 Git 的过程和git的简单使用。 先描述一下安装的需求： ・ 用户端和服务器端的操作系统都是 Windows。 ・ 用户端要能透过 HTTP 的方式存取版本库。 ・ 无论是取出档案还是送交档案，都需要验证身分(输入账号密码)。 底下是安装步骤： Step 1: 安装 Git for Windows 在 Windows 环境使用 Git，可以用 msysgit (Git for Windows)，我安装的版本是 v1.7.4。装好之后，程序集里面会多出一个选单：G...
Subversion 用得好好的，为什么要改用 Git 呢？ 记得刚开始用 Subversion 时，它在 Windows 平台上的工具也还不是那么方便，光是安装就要手动设定一堆东西。现在，Subversion 服务已经几乎是点下一步、下一步的方式就能安装完成了，非常方便。而且，现有的软件项目、写作等工作，也都在是用 Subversion 来管理版本。在已经投资不少学习成本、且用得很习惯的情况下，要换另外一套版本管理系统总是会有一些阻力。 更顺畅的工作流程 ...
在小站点上，直接用git来部署php代码是相当方便的事情，你的远程站点以及本地版本库都有一个版本控制，追踪问题或者回滚是很轻松的事情。下面介绍用git部署时的设置步骤。
