The readings and responses listed here should take you approximately 35 minutes total.
To start this assignment:
- Click the button in the upper right-hand corner that says Fork. This is now your copy of this document.
- Click the Edit button when you're ready to start adding your answers.
- To save your work, click the green button in the bottom right-hand corner. You can always come back and re-edit your gist.
Read David's article on Git and GitHub
- Use the article and outside resources (Google!) to describe the general process of a collaborative git workflow in the space below. My team all have access to our codebase, which is one repo (for now). We all clone the repo so we can do work locally, which means we all have a version of the same repo on our local machines. We all do work, hopefully on feature branches, and we push them up and create Pull Requests (PRs) for the work we've all done. Next, we review each other's work. If it seems legit, we approve and merge that PR into the develop branch (if we're using GitFlow). We should be doing regression testing along the way, to make sure that the individual features aren't breaking anything that was already functioning. At some point, our release branch will be cut from the develop branch and then merged into main after all testing passes.
Read this article on git commit messages
- Your key take-aways OR how you're going to implement specific points (minimum 2):
- I try to write descriptive commit messages that help me understand where I was at that point in time/space/development.
- I also try to commit often, because small breaks are easier to remove than big breaks (when there's a ton of code that you pushed and it broke things, it's hard to find the problem; I try to commit often so that the haystack is smaller and makes finding the needle easier).
- I've also found that keywords in my commit messages make it easier to find that topic later (like, years down the road). I've had to search through a codebase to find an old commit and try to determine the history of reasoning behind why a particular feature was developed, and the commit messages are the way that history is communicated (or at least they can be).
- Also -- I've never seen a title and body used in a commit message (never even knew you could add the body, outside of github!!). That was super interesting.