Introduction
In the previous article, you learned how to connect Git and GitHub by pushing the local directory Bakery to a remote repository.
Now that you've connected Git and GitHub, you can start taking care of your repository.
In this article, I'll teach you how to best take care of your project.
NOTE: You might want to be at a computer or laptop (to get the full experience).
Writing Commit Messages
One of the most important parts of having good practices in Git is writing descriptive commit messages.
This is very helpful for others viewing your code and commits, as well as your future self. Writing descriptive commits now is also helpful for backtracking, which I'll explain in the next article.
When it comes to actually writing the commit messages, there's no set way to write them. Some companies have different standards than others. This discussion proves how many different ways there are to write them - and they're all equally correct.
If you ask me, the best commit message is the most succinct (but still descriptive) one. It should go something like this:
<type>: <description>
[optional body]
[optional footer]
This post explains how to fill out the type, description, and optional body/footer.
Writing READMEs
Another important part of having good practices in Git is writing READMEs.
Below is a basic template that I plan to use for my projects. You can use it as well (sans credit to me).
Project Title: This is sorta self-explanatory (it's where your project title goes).
Description: This is a crucial component of the README. Use this section to describe the main purpose of your project. Why did you build it? What problems does it solve? What did you learn from making this project?
Features: This is the space to list your project's features. Don't be shy - brag unabashedly about your project's features, especially if they're unique to it and only it. You can even include screenshots and/or gifs to show them in action.
How to Use: This is where you write step-by-step instructions on how to install and use your project. This would also be the place to list software or package requirements (like npm).
Technologies: This is the place to list all technologies and/or frameworks you used. What purpose did they serve in your project? Optional question: Why did you choose what you chose over another similar framework?
Collaborators: This is where you need to give credit where credit is due. If you had help with this project, give the team member or collaborator a shoutout (with a link to their GitHub profile).
License: This is another crucial component of your README. Here is where you list a license (or three) so other developers understand what they can and cannot do with your project.
Part of crafting your README is knowing how to use Markdown. This guide by @atapas can help you use Markdown efficiently.
Conclusion
In this article, you learned how to have good habits in Git.
Great job on completing the sixth part of the series!
This is the 6th part of a 10 part series to teach Windows users about Git Bash. This series includes:
how to install Git Bash
how to navigate your file system
how to change your file system
how to set up Git and GitHub
how to connect Git and GitHub
how to backtrack in Git
how to branch in Git
...and more!!
Stay tuned for more - a new part will come out every Tuesday! 😊