How to commit your work into the project

[JaviTrek]

Okay so I know some of us are new to the whole github repo, some already know better. Either way, I'm going to give you some simple instructions on how to add your work properly to the repository.

Before you start developing, start on a new branch!

Not starting on a new branch might bring some issues (usually it doesn't but save yourself the headache). So inside your IDE, make sure to checkout on main and then create a new branch. I won't accept commits directly to main and will undo your commit if done like that (hopefully I setup protections to main well) . It is very bad ethic to make commits directly into production

Now write your branch name

Branch naming

Name your branch something relevant to the issue you are going to tackle. If you plan on working on the navbar, call it navbar or something similar. Dont name it "new-branch" or "Jake-Branch" or something unrelated to your work.

Small commits > Big commits

Since you have a branch just for your work, you can keep pushing commits without any fear. Therefore, its better to make small commits rather than just one huge commit. This is because it makes code more manageable and see to see when you we are merging your branch. Plus, lets say you created an express route or just finished putting the basic skeleton of a frontend element, its easier to remember what you did, type it and commit it in the moment than remembering what you did a week ago.

Its up to you how you manage your commits. I'd say the biggest factor is how complex is what you did, if its inserting a lot of new files and folders, I'd do a commit for the start of that, or if its something short but quite complicated function that took you really long, I'd make a commit just for that too. Its a big it depends.

Advantages of Small Commits and Continuous Improvement

• Getting early feedback from both tools (e.g. unit tests on a CI server) and other people (developers, testers, product managers) which encourages the idea of continuous improvement and helps to avoid large changes in the future.

• Revert a commit with ease if something goes wrong. Big commits are harder to revert since you may not want to revert all of the changes but only a subset.

• Small commits are easier to understand when reviewing a pull request.

• Write better commit messages. Since small commits are usually more focused and less broad than big commits, it is often easier to state the purpose of a small commit.

Use the Right Tool for the Job

Sometimes, small commits are not possible or reasonable:

• Splitting code changes into too many small commits can actually make it harder to review. If you changed the name of a variable that is used in 12 files then you should not create 12 separate commits. Since these changes belong together, they should be committed together, not separately.
• If you do a lot of small commits then it is easy to end up with large pull requests which can be hard to review even though each commit for itself may be relatively easy to understand. Therefore, you should avoid long-running branches which goes against the idea of continuous improvement

Don't install dependencies without discussing it first

Installing new dependencies can bring a lot of long term issues. I'm not too keen on dependencies for core functionality (such as creating our game grid). But, something to display charts, its okay to have chart.js because we shouldnt invest time developing code just for the one-two pages that display a chart, thats not a core functionality and therefore its okay for us to use a dependency for it.

Credits to: https://betterprogramming.pub/why-you-should-write-small-git-commits-c9a042737aa6