<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: Amy Gori</title>
    <description>The latest articles on Forem by Amy Gori (@amygori).</description>
    <link>https://forem.com/amygori</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F296952%2Feebe8b29-5040-4958-a29a-b6b0708d8c97.jpg</url>
      <title>Forem: Amy Gori</title>
      <link>https://forem.com/amygori</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/amygori"/>
    <language>en</language>
    <item>
      <title>What to do if you accidentally committed your node_modules</title>
      <dc:creator>Amy Gori</dc:creator>
      <pubDate>Thu, 06 Aug 2020 13:49:04 +0000</pubDate>
      <link>https://forem.com/momentum/what-to-do-if-you-accidentally-committed-your-nodemodules-323o</link>
      <guid>https://forem.com/momentum/what-to-do-if-you-accidentally-committed-your-nodemodules-323o</guid>
      <description>&lt;p&gt;So here you are, npm installing stuff, happily committing code in your project. Things are going well! While looking up a tricky bit of syntax, you stumble across the following advice: &lt;em&gt;Don't commit your node_modules!&lt;/em&gt; &lt;/p&gt;

&lt;h3&gt;
  
  
  Why don't you commit them?
&lt;/h3&gt;

&lt;p&gt;You don't need to track automatically generated files like &lt;code&gt;node_modules&lt;/code&gt;, which are the front end dependencies listed in your project's &lt;code&gt;package.json&lt;/code&gt;. Running &lt;code&gt;npm install&lt;/code&gt; will create (or update) &lt;code&gt;node_modules&lt;/code&gt;. There's no reason for these packages to be in version control, since npm can manage them for you. &lt;/p&gt;

&lt;h3&gt;
  
  
  But I already committed them 😕
&lt;/h3&gt;

&lt;p&gt;If you have already mistakenly committed these files, you need a way to tell git that you don't want to track them anymore. But you still want to keep them in your project, since they contain code that your project depends on. &lt;/p&gt;

&lt;p&gt;With git, there is (almost) always a way! Just follow these steps to get your repo in order.&lt;/p&gt;

&lt;h2&gt;
  
  
  Tell git to ignore &lt;code&gt;node_modules&lt;/code&gt;
&lt;/h2&gt;

&lt;p&gt;Git will exclude any files or directories listed in the aptly named &lt;code&gt;.gitignore&lt;/code&gt; file, so changes to files listed there will be treated as if they don't exist. Our first step is making sure &lt;code&gt;node_modules&lt;/code&gt; is on the gitignore list.&lt;/p&gt;

&lt;p&gt;If you don't have a gitignore file, now's a great time to make one! You can get ready-made, project-specific contents at &lt;a href="https://www.toptal.com/developers/gitignore"&gt;gitignore.io&lt;/a&gt;, but you can make a new empty file now and add more to it later.&lt;/p&gt;

&lt;p&gt;For all the following commands, you'll need to use the command line (don't type the &lt;code&gt;$&lt;/code&gt;; that just indicates the command line prompt).&lt;/p&gt;

&lt;p&gt;If you need to, create a gitignore file at the project root:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;$ touch .gitignore
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;p&gt;Open &lt;code&gt;.gitignore&lt;/code&gt; in your code editor and add the name of the directory you don't want git to track, anywhere in that file:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;# anywhere in .gitignore
node_modules
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;p&gt;This is a &lt;em&gt;pattern&lt;/em&gt; for git to match, not a &lt;em&gt;path&lt;/em&gt;, so it will ignore any file or directory in your repo named 'node_modules'.&lt;/p&gt;

&lt;p&gt;Go ahead and add the gitignore file to be committed. We definitely want other project contributors not to track &lt;code&gt;node_modules&lt;/code&gt;.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;$ git add .gitignore
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;p&gt;If you had not already committed &lt;code&gt;node_modules&lt;/code&gt;, this step would be all you need. You could go ahead and commit the changes and you'd be done.&lt;/p&gt;

&lt;h2&gt;
  
  
  Remove the files from git's index
&lt;/h2&gt;

&lt;p&gt;If you committed &lt;code&gt;node_modules&lt;/code&gt; before they were added to the gitignore file, git is going to notice changes each time you add and install a new package, when the &lt;code&gt;node_modules&lt;/code&gt; directory changes. So we need one more step to seal the deal.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;$ git rm -r --cached node_modules
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;p&gt;What you will see now if you check &lt;code&gt;git status&lt;/code&gt; is that any files in &lt;code&gt;node_modules&lt;/code&gt; that were shown in red are now in green. This means that they are staged in git. They are also marked as &lt;code&gt;deleted&lt;/code&gt;. &lt;/p&gt;

&lt;h4&gt;
  
  
  Details of what this command does
&lt;/h4&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;code&gt;rm&lt;/code&gt; is a &lt;a href="https://git-scm.com/docs/git-rm"&gt;git command&lt;/a&gt; that tells git to stage the removal of the file from tracking.&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;-r&lt;/code&gt; is an option that tells git to perform the &lt;code&gt;rm&lt;/code&gt; command recursively. A recursive operation is necessary because we have a directory that contains other files and other directories, so we have to dig into each of those to delete all of them.&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;--cached&lt;/code&gt; refers to git's cache, also called the &lt;em&gt;index&lt;/em&gt;, where changes to files can be staged for committing. This option ensures that &lt;em&gt;we are not deleting the files themselves&lt;/em&gt;, only removing the reference to their changes.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Now we need to commit our changes. This commit will include our &lt;code&gt;.gitignore&lt;/code&gt; addition from the previous step.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;git commit -m "Remove and ignore node_modules"
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;p&gt;And now, huzzah! 🎉 Your project dependencies are still intact, but &lt;code&gt;node_modules&lt;/code&gt; will no longer show up in your git index when they change. You can safely push this commit to GitHub, where you will no longer see a &lt;code&gt;node_modules&lt;/code&gt; directory in your project. That's what we want!&lt;/p&gt;

&lt;h2&gt;
  
  
  This works with any other files you've accidentally committed
&lt;/h2&gt;

&lt;p&gt;You can use these same steps for anything else that you accidentally commit. Add the file to your &lt;code&gt;.gitignore&lt;/code&gt;, then use &lt;code&gt;git rm --cached &amp;lt;filename&amp;gt;&lt;/code&gt; to stage the deletion of the file from the index. For example:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight"&gt;&lt;pre class="highlight plaintext"&gt;&lt;code&gt;$ git rm -r --cached static/js/webpack_bundles
$ git rm --cached webpack-stats.json # if it's a file, you don't need the recursive option
&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;



&lt;h3&gt;
  
  
  Take extra steps to deal with sensitive information
&lt;/h3&gt;

&lt;p&gt;It's important to note that &lt;code&gt;git rm&lt;/code&gt; will remove files in current and future commits, but &lt;em&gt;will not remove them from the history&lt;/em&gt;. This usually doesn't pose a problem, but if you've accidentally committed a file that should be erased from history because it contains sensitive information (like API keys or credentials for services like AWS), consult &lt;a href="https://docs.github.com/en/github/authenticating-to-github/removing-sensitive-data-from-a-repository"&gt;GitHub's comprehensive guide on what to do&lt;/a&gt;.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why all the fuss, git?
&lt;/h2&gt;

&lt;p&gt;Git's whole purpose is to track what has changed in your project. When a file gets created in a git repo, you have to explicitly tell git to start tracking that file in the first place. For a complete record of what has happened in the course of project development, we &lt;em&gt;also&lt;/em&gt; want to record when those files are deleted or no longer tracked. That is what we use &lt;code&gt;git rm&lt;/code&gt; to do and why a commit is made. It's just another bookmark in the history. &lt;/p&gt;

</description>
      <category>npm</category>
      <category>git</category>
      <category>github</category>
      <category>beginners</category>
    </item>
  </channel>
</rss>
