<?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 Rietta Cybersecurity</title>
    <link>https://rietta.com/tags/git/</link>
    <description>Recent content in Git on Rietta Cybersecurity</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <copyright>1999-2026 Rietta Inc. All Rights Reserved.</copyright>
    <atom:link href="https://rietta.com/tags/git/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Acknowledge Open-Source Contributors with Git Authorship</title>
      <link>https://rietta.com/blog/acknowledge-open-source-contributors-with-git-authorship/</link>
      <pubDate>Mon, 07 Oct 2019 10:00:00 -0600</pubDate>
      <guid>https://rietta.com/blog/acknowledge-open-source-contributors-with-git-authorship/</guid>
      <description>Even though Git has been around since 2005 and has definitely taken over as the primary VCS, some developers do not utilize git to the fullest of its ability. Some developers even intentionally execute commands to remove functionality, such as replacing commit authors with their own. Additionally, it&amp;rsquo;s shocking that some of these mishaps occur in popular repositories, such as vim, but often maintainers express no intention of changing. In modern times, Github has fortunately made the process of keeping git authors intact trivial.</description>
    </item>
    <item>
      <title>Why do Rietta Developers Git Fork?</title>
      <link>https://rietta.com/blog/why-git-fork/</link>
      <pubDate>Wed, 25 Sep 2019 13:00:00 -0400</pubDate>
      <guid>https://rietta.com/blog/why-git-fork/</guid>
      <description>Why Fork a repository? Forking a open source project is the standard way for collaborators such as ourselves to fix bugs, experiment, and add features to existing open source projects without affecting the main repository. We can use the Fork feature on Github to create a repo on Github in which is a clone of the original repo we forked.&#xA;Github has a great article https://help.github.com/en/articles/fork-a-repo that explains how we can fork off from a repository on Github.</description>
    </item>
    <item>
      <title>What&#39;s the Difference Between the 3 Github Merge Methods?</title>
      <link>https://rietta.com/blog/github-merge-types/</link>
      <pubDate>Fri, 07 Jun 2019 13:00:00 -0400</pubDate>
      <guid>https://rietta.com/blog/github-merge-types/</guid>
      <description>Keeping a clean git history can save a lot of time when trying to track down commits related to a bug or issue that is disrupting dev efforts. GitHub provides three options when merging in commits, these three options being:&#xA;Create a Merge Commit Squash and Merge Rebase and Merge Merging with a merge commit, squash merging, and &amp;ldquo;Rebase &amp;amp; Merge&amp;rdquo; should be pretty familiar as these are commands that are already commonly used when working on dev branches to keep commits on PRs tidy.</description>
    </item>
    <item>
      <title>Manually Editing Git Hunks: The Easy Way</title>
      <link>https://rietta.com/blog/git-patch-manual-split/</link>
      <pubDate>Thu, 23 May 2019 12:10:00 -0400</pubDate>
      <guid>https://rietta.com/blog/git-patch-manual-split/</guid>
      <description>If you&amp;rsquo;ve been following our Git related posts, you probably notice we use git add --p with many of the examples used. This a great way for developers to split up code changes on one file to their own commit message. Not only will this make your pull requests cleaner, but will allow the code reviewer to get valuable context when diving into code changes on said file.&#xA;Git add patch gives us many options: Stage this hunk [y,n,q,a,d,e,?</description>
    </item>
    <item>
      <title>How to hide .gitignored Files from fzf.vim</title>
      <link>https://rietta.com/blog/hide-gitignored-files-fzf-vim/</link>
      <pubDate>Tue, 21 May 2019 10:30:00 -0400</pubDate>
      <guid>https://rietta.com/blog/hide-gitignored-files-fzf-vim/</guid>
      <description>&lt;p&gt;&lt;img src=&#34;https://rietta.com/assets/blog/hide-gitignored-files-fzf-vim/phoenix_hello_world_fzf_deps.png&#34; alt=&#34;Messy Phoenix Fuzzy Finder&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;Fuzzy finders find files that almost no developer would intentionally find via a fuzzy finder from paths&#xA;such as &lt;code&gt;node_modules/&lt;/code&gt;, &lt;code&gt;deps/&lt;/code&gt;, and &lt;code&gt;dist/&lt;/code&gt;. These tend to get in the way of the true power of fuzzy file&#xA;searching and ignoring these individually can be a pain. There are also files like &lt;code&gt;.circleci/config.yml&lt;/code&gt;,&#xA;&lt;code&gt;.gitignore&lt;/code&gt;, and &lt;code&gt;.rubocop.yml&lt;/code&gt; that are opened often enough to be included in the result set.&lt;/p&gt;&#xA;&lt;p&gt;Luckily when working in a git repository, developers typically only care about the files they commit.&#xA;When using &lt;a href=&#34;https://github.com/junegunn/fzf.vim&#34;&gt;fzf.vim&lt;/a&gt;, this technique returns&#xA;files based on the git tree leaving out irrelevant files, including the hidden files that were&#xA;shown before.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Restrict Who Can Push to Matching Branches on Github</title>
      <link>https://rietta.com/blog/git-branch-protection/</link>
      <pubDate>Thu, 09 May 2019 11:00:00 -0500</pubDate>
      <guid>https://rietta.com/blog/git-branch-protection/</guid>
      <description>&lt;p&gt;An anonymous attacker has been compromising Git repositories and demanding ransom. This attacker stole the contents and used a &lt;code&gt;force push&lt;/code&gt; to wipe the remote repository causing many to lose access to their critical source code assets. Use critical security tools available within the Git ecosystem to protect your company from this threat with:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Deploy Keys&lt;/li&gt;&#xA;&lt;li&gt;Mandatory Two Factor Authentication&lt;/li&gt;&#xA;&lt;li&gt;Protected Branches and Pull Requests&lt;/li&gt;&#xA;&lt;li&gt;Backups of your Git Repositories&lt;/li&gt;&#xA;&lt;/ul&gt;</description>
    </item>
    <item>
      <title>Fixup your Code Reviews with git rebase --autosquash</title>
      <link>https://rietta.com/blog/git-rebase-autosquash-code-reviews/</link>
      <pubDate>Tue, 07 May 2019 11:00:00 -0400</pubDate>
      <guid>https://rietta.com/blog/git-rebase-autosquash-code-reviews/</guid>
      <description>Here at Rietta, we like to do in-depth code reviews that are sometimes accompanied with feedback that may require changes to be made to the pull request. When making additional commits with changes based on the feedback, we can get into a messy workflow that can lead to complex branch wrangling.&#xA;In this article, I will go over a few Git commands to help ease our post code-review revisions:&#xA;git commit --fixup commit-SHA git rebase -i --autosquash source-branch Our team utilizes Github&amp;rsquo;s Squash and merge when merging into master, with semantic git commits that are specific to their respective code changes.</description>
    </item>
    <item>
      <title>How to Use git reset</title>
      <link>https://rietta.com/blog/git-reset/</link>
      <pubDate>Mon, 22 Apr 2019 16:00:00 -0400</pubDate>
      <guid>https://rietta.com/blog/git-reset/</guid>
      <description>The command git reset is a powerful tool that Rietta staff use on a daily basis. However powerful, git reset has 2 distinct features:&#xA;Hard resets, in which will modify the working tree Soft resets, in which will modify the index Often you&amp;rsquo;ll hear that the reset command is basically the opposite of the add command. While this is true for the default reset, there are other options to reset the index without unstaging the files as well.</description>
    </item>
  </channel>
</rss>
