Is it better to replace my old GitHub commit or create a new one?

Hey everyone! I’m pretty new to GitHub and have a question about commits. I made my very first commit to my repository about a year ago and haven’t touched it since then. Now I want to add some new changes to my project.

I’m not sure what the best practice is here. Should I somehow replace or modify that old commit I made last year? Or is it better to just create a brand new commit with my current changes?

Also, if I do decide to replace the old commit, what’s the proper way to do that? I’ve heard about things like rebasing but I’m not really sure how that works or if it’s the right approach for my situation.

Any advice would be really helpful. Thanks!

Definitely go with a new commit. Amending or rebasing that year-old commit is overkill and could cause problems. Version control tracks changes over time - gaps between commits are totally normal and actually show how your project evolved. Just stage your changes and commit normally. Git handles this perfectly. If you mess with the old commit, you’re rewriting history, which breaks things if others use your repo or you need to revert later. Keep it simple and let your commits show the real timeline.

Just make a new commit - don’t overthink it. There’s no rule about committing regularly. Personal projects sit untouched for months all the time. Rewriting that old commit isn’t worth the hassle and could break things if you’ve shared the repo.

It’s advisable to create a new commit rather than alter the old one. Each commit serves as a snapshot, which is essential for maintaining a clear history of your project’s progress. Modifying old commits can lead to complications, especially if your repository has been cloned by others. Generally, you should only change commits to rectify recent errors. In your case, adding your current changes as a new commit will help keep your project’s history organized.

Just create a new commit - that’s definitely the right move. I learned this the hard way: commits should document your actual dev journey, not look perfect. That year gap? It tells the real story of your project’s lifecycle. When I started with Git, I kept trying to rewrite history to make everything look clean. Big mistake. It created massive headaches later when I needed to track down specific changes. Your old commit shows where the project was back then, and the new one shows how it’s evolved. Keep it simple and follow Git’s core principle - preserve history, don’t rewrite it.

This topic was automatically closed 4 days after the last reply. New replies are no longer allowed.