I’m working on a GitHub project that I started about a year ago. Back then, I made my very first commit to the repository. Now I need to make some changes and push new code to the same project.
I’m wondering what the best approach would be: Should I overwrite that original commit I made last year, or would it be better to just create a fresh commit on top of it? I’m not sure which method is considered good practice.
Also, if replacing the old commit is the right way to go, what’s the proper procedure to do this? I want to make sure I don’t mess anything up since I’m still learning how Git and GitHub work together.
Always go with a new commit. The other answers are right about preserving history.
But here’s a thought - if you’re working solo and want more control over your workflow, automate parts of your Git process. I’ve seen too many devs wreck their repos from forgetting steps or making manual mistakes.
I automate commit formatting, branch management, even deployment triggers. Removes the guesswork and prevents those “oops I broke everything” moments.
For now, just do your usual git add, commit, and push. But think about automating future Git workflows - it’ll make development smoother and more reliable.
Latenode makes this automation pretty straightforward. You can create workflows that handle Git operations based on whatever triggers you set up.
yeah, def make a new commit. rewriting the old one means force pushing, which is kinda risky - especially if you’ll have collabs in the future. just keep it simple and build on what ya already have.
Don’t touch that old commit. Everyone’s right about preserving history, but here’s why it really matters - rewriting pushed commits means force pushing, and that can nuke your work if you mess up. I learned this the hard way when I accidentally wiped weeks of progress trying to clean up an old commit. Just do the normal workflow: make changes, git add, commit with a good message about what you changed, then push. That year-old commit is actually useful - it’s a snapshot of where your project was back then. You’ll thank yourself later when you’re hunting down bugs or trying to remember how something evolved. Git’s built for exactly this - adding new work on top of old commits.
Creating a new commit is definitely the best approach. Overwriting your previous commit can disrupt the commit history, particularly if other collaborators are involved. It’s crucial to maintain a clean history, which also helps you to reference your past work if needed. A new commit allows your original code to remain unchanged, with your latest modifications layered on top. This method aligns with Git’s intended functionality. Simply use git add, followed by git commit -m "your message", and then push your changes as usual.
Just create a new commit. Don’t rewrite that year-old commit - you’ll mess up your repo’s history, which goes against Git’s whole immutable history thing. I made this mistake early on when I tried amending an old commit and completely confused myself about what changed when. Your commit history is basically a timeline of your project. That old commit might look outdated now, but it shows where your head was at the time. Super helpful when you’re debugging later or trying to remember why you made certain decisions. Just run git add on your changes, write a good commit message explaining what you updated after the year break, and push. You’ll be glad you kept that clean chronological record.
for sure, just create a new commit! overwriting the old one can mess up the commit history, especially if others are colaborating. plus, keeping the old code is helpful, you never know when you might need to refer back to it!