To review changes to our application code, we use a tool called “git” that helps us keep track of changes to all of our source code in a “repository,” or “repo” for short. We have one repo per application.
A companion to git is GitHub. There’s a free, public version of GitHub at github.com, but the University also maintains an enterprise version at github.umn.edu that we primarily use.
Whenever we make changes to our code, it’s stored as a git “commit.” We write a message for each commit. In that message, we try to provide the context for why we’re making a code change. This is very helpful when we want to trace the history of code changes. We can see messages we left for ourselves about why a change was made, and when. That history is extremely important, so we tend to write longish commit messages. They’re letters from our past.
Once we’re confident that our code changes are ready, we submit a “pull request” in GitHub that notifies the team. We can then see the changed code and review it. This is the time to ask questions and give suggestions. We’ve built up a healthy culture of supporting each other in pull request reviews.
Once a developer approves a pull request, we “merge” it. That just means it gets included with our deployable code. Some of our longer-lived applications have thousands of commits and pull requests. This gives us a rich history that’s especially helpful when working on fixing bugs.
No comments:
Post a Comment