Platform for secondary school higher level graduate to get information about various universities and admission requirement
Steps to follow to work on this repository
- Fork, watch and star the reposidtory: This will creat a copy of the repository in your github account.
- Clone the repository on your local machine
- Open the project on your favorite code editor and run.
- Take an issue and work on it .
- if you take an issue, please indicate that you are working on it so that two people will not be working on the same issue
- If you resolve the issue, first do 'git pull' to be up to date before pushing
- While pushing make sure you write a good commit massage.
- After pushing to your github account, send a pull request so that your work will be merge.
Beginners should follow this link to familiarise themselves
https://dont-be-afraid-to-commit.readthedocs.io/en/latest/git/commandlinegit.html
https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners
--What To Include In A Commit
-
I've been telling you what files to create, giving you the content to include, and telling you when you should make commits. But when you're on your own, how do you know what you should include in a commit and when/how often you should make commits?
-
The goal is that each commit has a single focus. Each commit should record a single-unit change. Now this can be a bit subjective (which is totally fine), but each commit should make a change to just one aspect of the project.
*Now this isn't limiting the number of lines of code that are added/removed or the number of files that are added/removed/modified. Let's say you want to change your sidebar to add a new image. You'll probably:
add a new image to the project files alter the HTML add/modify CSS to incorporate the new image A commit that records all of these changes would be totally fine!
-
Conversely, a commit shouldn't include unrelated changes - changes to the sidebar and rewording content in the footer. These two aren't related to each other and shouldn't be included in the same commit. Work on one change first, commit that, and then change the second one. That way, if it turns out that one change had a bug and you have to undo it, you don't have to undo the other change too.
-
The best way that I've found to think about what should be in a commit is to think, "What if all changes introduced in this commit were erased?". If a commit were erased, it should only remove one thing.