Stop tracking and start ignoring

Vijay Koushik, S. 👨🏽‍💻 on February 18, 2019

Hello world, I’ve been playing around with GitHub & Git over the past few months and most of the time I accidentally commit and push files t... [Read Full]
markdown guide
 

You should not ignore package.json, it is a key file shared between all the developers defining package dependencies. You should ignore build artefacts and installed dependencies and user specific configuration files such as IDE configuration, that is specific to a single user. Note that some IDE config files you don't want to ignore such as build configurations because they're the same for the whole team.

 

True. Also Gemfile and Gemfile.lock should be included for the same reason.

 

It's worth mentioning that both package.json and package-lock.json should be included in the repo. The first allows to install dependencies fresh, and the second one is necessary for the npm ci command, indispensable for any continuous integration setup. I've seen people who kept package.json but ignored the lockfile, and it did cause me problems a few times...

 

Wow! Thank you so much for your valuable comments everyone. But, in my defense I want to make it clear why I talked about deleting package.json and Gemfile.lock files.

  1. I said I deleted the package.json file because, The project was my personal static website hosted on GitHub pages. I used gulp as a dev dependency and to me it was never needed to be on the repo since I use a single machine for development.
  2. I talked about me deleting the Gemfile.lock file because, my blog is also hosted on GitHub pages and is rendered with Jekyll. So, I do not know the consequences of keeping the file in the repo which is deployed in an environment which I don't have control of.

Thank you all again for pointing out the importance of package.json, package-lock.josn, Gemfile and Gemfile.lock files being in the repo 🙂

 

This is true.

package.json should exist in case one of your dependencies in package-lock.json is platform specific and package.json is used for finding a compatible version.

 

That's not why this happens. It happens because you're adding those files in the first place. Why are files you don't want to push even being tracked? git add is meant to be a targeted operation, performed only on those files you want in the repo. Don't git add * or (worse) git add -A and you won't have this problem.

 

(I love .gitignore for it's ability to hide things from the "Untracked Files" list in git status. Because if you're not planning on tracking those files, get them off the list so that git can warn you if you haven't added any that you SHOULD be tracking.)

 

Thank you for sharing about git add command. Like I said in this comment, I use the GitHub Desktop app to commit and push my changes to the remote repo. Since It automatically adds all new files to the tracking list, The issue of committing unwanted files occurs when I'm not vigilant enough 😐.

 

Thanks for the post and the useful links/images. This particular scenario can really be frustrating :)

Btw have you read a book on git? I found that a good book on git is much more valuable than guides / videos in that scenarios like this one occurred very very, infrequently as a result because of my deeper understanding.

 

well, I'd say RTFM is the first thing to do :D
and git does have great official documentation ( git-scm.com/book/ )

 

Yep. Sometimes I like some sugar sprinkled over the documentation. I think that's why a book like "You dont know JS" is so popular :)

For git there is a book with actual exercises that helped me solidify the concepts - Git in a Month of Lunches.

 

You're right!😅 Reading the manual or a book as mentioned by @tinmanjk should've been my first action when I was playing with GitHub repos. But GitHub's easy to use web interface and the GitHub App made me think that I did not need to look into the Git documentation. And thank you for the link to the e-book 👍🏽.

You're welcome. I think it's essential to have a safe environment to mess with a new thing in order to learn better the ins and outs. Unfortunately with source control it's generally not advisable to do that :) So here come the exercises, a way to progressively learn.

 

Rather than have just a project-specific .gitignore, which could contain the world, have one per project and a global config that includes all the common trash files (like the __MACOSX and .DS_Store files that Macs leave littered around the place, or Thumbs.db that Windows generates) and a generic list of IDE trash like .nb_project or whatever.

Some OS and applications are really quite bad citizens but it doesn't need to add commits to your project.

 
 

Thank you for sharing!

I agree. It's a very powerful git command every developer should be aware of!

 
 
 

That is one good collection 👍🏽. I actually came across this repository when writing this article. I did not mention this because, in the article I talked about me realizing that I did not add a .gitignore file after making a few commits to the repo and in my perspective it seemed a bit of extra work to select the templates for Operating system, programming language and IDE separately instead of providing the above mentioned as input and get a combined file. Thanks for mentioning this good collection of templates here :)

code of conduct - report abuse