<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Git on Shafiq Alibhai</title>
    <link>https://www.shafiq.in/zh/tags/git/</link>
    <description>Recent content in Git on Shafiq Alibhai</description>
    <generator>Hugo</generator>
    <language>zh-CN</language>
    <copyright>© 2009-2026 All rights reserved.</copyright>
    <lastBuildDate>Fri, 12 Oct 2018 09:49:17 +0000</lastBuildDate>
    <atom:link href="https://www.shafiq.in/zh/tags/git/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>How to Fix the &#34;RPC failed; HTTP 413 curl 22&#34; Error in Nginx</title>
      <link>https://www.shafiq.in/zh/blog/how-to-fix-the-rpc-failed-http-413-curl-22-error-in-nginx/</link>
      <pubDate>Fri, 12 Oct 2018 09:49:17 +0000</pubDate>
      <guid>https://www.shafiq.in/zh/blog/how-to-fix-the-rpc-failed-http-413-curl-22-error-in-nginx/</guid>
      <description>&lt;h2 id=&#34;understanding-the-issue-rpc-failed-http-413-curl-22&#34;&gt;Understanding the Issue: &amp;lsquo;RPC failed; HTTP 413 curl 22&amp;rsquo;&lt;a class=&#34;anchor&#34; href=&#34;#understanding-the-issue-rpc-failed-http-413-curl-22&#34;&gt;#&lt;/a&gt;&lt;/h2&gt;&#xA;&lt;p&gt;If you&amp;rsquo;ve stumbled upon the error message &amp;ldquo;RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large,&amp;rdquo; you&amp;rsquo;re probably trying to push a rather hefty commit over HTTP to your server running Nginx. This error means that the size of the request you&amp;rsquo;re trying to send exceeds the limit that the server is willing to accept. So, how do you fix it?&lt;/p&gt;</description>
    </item>
    <item>
      <title>Merging Unrelated Git Histories - A Simple Guide</title>
      <link>https://www.shafiq.in/zh/blog/merging-unrelated-git-histories-a-simple-guide/</link>
      <pubDate>Tue, 04 Sep 2018 13:48:55 +0000</pubDate>
      <guid>https://www.shafiq.in/zh/blog/merging-unrelated-git-histories-a-simple-guide/</guid>
      <description>&lt;p&gt;Are you stuck with two Git repositories or branches that have completely different histories, but you need to merge them? You may be hitting a roadblock because Git is designed to prevent this kind of operation by default. However, there&amp;rsquo;s a workaround for this, and it&amp;rsquo;s simpler than you might think.&lt;/p&gt;&#xA;&lt;h3 id=&#34;the-problem-unrelated-git-histories&#34;&gt;The Problem: Unrelated Git Histories&lt;a class=&#34;anchor&#34; href=&#34;#the-problem-unrelated-git-histories&#34;&gt;#&lt;/a&gt;&lt;/h3&gt;&#xA;&lt;p&gt;Imagine you&amp;rsquo;re working on a project where you have a &lt;code&gt;main&lt;/code&gt; branch, and someone else has a completely separate project with its own history. Now, you want to combine both projects into a single repository. If you try to perform a regular &lt;code&gt;git merge&lt;/code&gt; or &lt;code&gt;git rebase&lt;/code&gt;, Git will likely stop you with an error message, something like:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Navigating Release Engineering - A Step-by-Step Plan</title>
      <link>https://www.shafiq.in/zh/blog/navigating-release-engineering-a-step-by-step-plan/</link>
      <pubDate>Thu, 30 Aug 2012 17:14:59 +0000</pubDate>
      <guid>https://www.shafiq.in/zh/blog/navigating-release-engineering-a-step-by-step-plan/</guid>
      <description>&lt;h1 id=&#34;the-blueprint-for-a-smooth-release-engineering-process&#34;&gt;The Blueprint for a Smooth Release Engineering Process&lt;a class=&#34;anchor&#34; href=&#34;#the-blueprint-for-a-smooth-release-engineering-process&#34;&gt;#&lt;/a&gt;&lt;/h1&gt;&#xA;&lt;p&gt;Isn&amp;rsquo;t it satisfying when everything falls into place just as you&amp;rsquo;d hoped? In the complex world of development, where multiple cogs are in motion at any given time, having a well-defined plan can make all the difference. Here&amp;rsquo;s a streamlined guide to setting up a robust Release Engineering (Releng) system that ensures efficient and error-free deployments.&lt;/p&gt;&#xA;&lt;h2 id=&#34;step-by-step-implementation&#34;&gt;Step-by-Step Implementation&lt;a class=&#34;anchor&#34; href=&#34;#step-by-step-implementation&#34;&gt;#&lt;/a&gt;&lt;/h2&gt;&#xA;&lt;h3 id=&#34;1-version-control-with-git&#34;&gt;1. Version Control with Git&lt;a class=&#34;anchor&#34; href=&#34;#1-version-control-with-git&#34;&gt;#&lt;/a&gt;&lt;/h3&gt;&#xA;&lt;p&gt;We begin by storing all our configuration files and Puppet manifests in a Git repository. It serves as the central hub where changes are tracked and updated.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Practical Guide to Release Engineering - Mastering Version Control with Subversion</title>
      <link>https://www.shafiq.in/zh/blog/a-practical-guide-to-release-engineering-mastering-version-control-with-subversion/</link>
      <pubDate>Wed, 11 May 2011 16:38:57 +0000</pubDate>
      <guid>https://www.shafiq.in/zh/blog/a-practical-guide-to-release-engineering-mastering-version-control-with-subversion/</guid>
      <description>&lt;p&gt;Subversion is more than just a tool for tracking changes in your code. It can be a cornerstone of an effective release engineering strategy, offering features that facilitate a smooth transition of code from development to production. Here, we&amp;rsquo;ll explore two techniques you can employ: utilizing revision numbers and creating tags.&lt;/p&gt;&#xA;&lt;p&gt;Most people who have dabbled in Subversion are familiar with revision numbers. Let&amp;rsquo;s say you make a commit and your code becomes &amp;ldquo;revision 1234.&amp;rdquo; You can then export this specific revision to your development environment for testing. Once it passes your rigorous checks, it&amp;rsquo;s off to the QA environment for further scrutiny.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
