In my quest to to contribute more to open source projects, I have been learning to use Git. There are many guides out there but I have come to the conclusion that they are all written for those that are more experienced than I am. I seem to have to scratch my head a bit when the commands didn’t work for me. As a result, I am writing this guide for me.
This is also being written for using GitHub as that is the service I have chosen to use at this time.
Workflow
This is a quick summation of the branch-based workflow to aid in remember what they are without flipping through this resource from GitHub.com.
Create a branch
When you create a branch in your project, you’re creating an environment where you can try out new ideas. Changes you make on a branch don’t affect the main branch, so you’re free to experiment and commit changes, safe in the knowledge that your branch won’t be merged until it’s ready to be reviewed.
Add commits
Whenever you add, edit, or delete a file, you’re making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change.
git add <filename>
or if you want to add everything
git add *
Then you have to commit the changes with the following command
git commit -m "Commit message"
Open a Pull Request
Pull Requests initiate discussion about your commits. Because they’re tightly integrated with the underlying Git repository, anyone can see exactly what changes would be merged if they accept your request.
To help me think of this process properly, the idea is to pull this branch back into the main branch.
Discuss and review your code
The person or team reviewing your changes may have questions or comments. Perhaps the coding style doesn’t match project guidelines, the change is missing unit tests, or maybe everything looks great and props are in order.
Deploy
Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing main branch into production.
Merge
Once merged, Pull Requests preserve a record of the historical changes to your code. Because they’re searchable, they let anyone go back in time to understand why and how a decision was made.
Final Thoughts (Supplemental)
This is still a work in progress. It has only been published so I can access this later.
References
https://rogerdudler.github.io/git-guide/
https://www.linux.com/topic/desktop/how-integrate-git-your-linux-desktop/
https://www.sitepoint.com/github-cli/
http://hackerpublicradio.org/eps.php?id=2664
https://guides.github.com/introduction/git-handbook/