Early Software Engineering Problems: Bad Pull Requests

Just two days ago, I made a big history for my self: Opening a bad pull request for the production branch for the company I am interning in.

Even though my code was thankfully not really the problem, I still requested and committed the database connection settings to be pushed in the production branch, with the username, the server name, and the password, copied it twice, and pushed it without looking at my history of pushes.

This was only one feature, but this could bring so much vulnerability to the code. Which is, inevitably, very destructive and insanely disruptive to the company's security of code and overall data. So, what should one do to prevent this?

1. Most importantly, commit step-by-step. Even if you made a lot of changes, do not commit all of it in one go, commit the files step-by-step. For example, if you made two services, an interface, and a model. Make sure to commit whichever you made first, for example, the model first, then the services, and then the interface. Why? The model and the services would already work without the interface, the interface adds readability and maintainability to the code base.
2. Make sure to recheck every single pages you want to commit, and the commit message, even when you are extremely tired or sleepy. What files are going to be committed?What is the context of the files? Such as separating name changes and logical changes in different contexts.Make sure that one commit only has one specific job.
3. Lastly, pray that your senior also checks your pull request completely. Inevitably, we are humans; hence, we could make mistakes - but that doesn't necessarily mean we do not have any responsibilities.

Well, what do you do if you committed and pushed the wrong code?

1. If it involves credential information like mine, just move the head of the branch and force commit. NO QUESTIONS ASKED git reset --hard HEAD^ and git push origin -f
2. If it doesn't there is always ways to ammend and revert the code, however you want.

Finally, what I did was choice number 1, and it saved people from seeing my commit history which could badly interfere the company's security. And, yesterday, was my first time getting a code accepted into a company's code monolithic base. I hope from reading this, you guys can learn from my mistakes. Happy coding!

Picture Credit: https://arc.dev/employer-blog/avoid-failed-software-projects/

"Success is not final, failure is not fatal: It is the courage to continue that counts.” —Winston Churchill.