<?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 Bitsy Services Wiki</title>
    <link>https://wiki.bitsy.services/wiki/git/</link>
    <description>Recent content in Git on Bitsy Services Wiki</description>
    <generator>Hugo</generator>
    <language>en</language>
    <atom:link href="https://wiki.bitsy.services/wiki/git/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Squash Merge</title>
      <link>https://wiki.bitsy.services/wiki/git/squash-merge/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://wiki.bitsy.services/wiki/git/squash-merge/</guid>
      <description>&lt;p&gt;A &lt;strong&gt;squash merge&lt;/strong&gt; collapses every commit on a feature branch into a single new commit on the target branch. Instead of replaying the branch&amp;rsquo;s history one commit at a time, Git combines all of the branch&amp;rsquo;s changes into one diff and lands that as a lone commit. The original per-commit history of the branch is discarded from the target branch&amp;rsquo;s record.&lt;/p&gt;&#xA;&lt;p&gt;It is the workflow of choice when the branch&amp;rsquo;s intermediate commits are noise &amp;ndash; &amp;ldquo;wip&amp;rdquo;, &amp;ldquo;fix typo&amp;rdquo;, &amp;ldquo;address review&amp;rdquo; &amp;ndash; and only the net change is worth keeping in the permanent history.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Submitting a PR to a Third-Party Repo</title>
      <link>https://wiki.bitsy.services/wiki/git/contributing-to-open-source/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://wiki.bitsy.services/wiki/git/contributing-to-open-source/</guid>
      <description>&lt;p&gt;Opening a pull request against someone else&amp;rsquo;s open source project is as much a social act as a technical one. You are asking a maintainer &amp;ndash; usually an unpaid volunteer with a backlog &amp;ndash; to read your change, trust it, and take on the burden of maintaining it forever. The best contributions minimize that burden: they are small, they follow the project&amp;rsquo;s existing conventions, and they arrive with enough context that the maintainer can say yes without a second round of questions. This page is an opinionated checklist for getting a change merged into a repository you don&amp;rsquo;t control.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
