Labs are hands-on coding projects that you build along with Tonya as she explains the code, concepts, and thought processes behind it. You can use the labs to further your code knowledge or to use right in your projects. Each lab ties into the Docx to ensure you have the information you need.
Each lab is designed to further your understanding and mastery of code. You learn more about how to think about its construction, quality, maintainability, programmatic and logical thought, and problem-solving. While you may be building a specific thing, Tonya presents the why of it to make it adaptable far beyond that specific implementation, thereby giving you the means to make it your own, in any context.
In this episode, let’s talk about what you will be doing in this hands-on coding lab. We’ll also talk about what you need to have installed, setup, and configured on your local machine in order to do this lab. Make sure you have git installed and globally configured. If no, go do either the Mac or Windows Local Development Setup lab.
Let’s dive into git log to uncover what information it provides to you, how to format the information, and how you can filter to find what you are looking for in the report. Remember, the log is a report of your commit history.
In the last episode, I showed you how you can view the changes in each of the commits in the GitHub UI. But you can view differences in the command line too using git diff.
When you have a new project, how do you put it into version control? You navigate to the root folder of the project, i.e. the theme or plugin, and run the command git init. Git then installs a new hidden folder inside of your project. That folder has what git needs to track that individual project. In this episode, you’ll put the TwentySeventeen theme into version control and then look inside of its hidden .git folder.
When you contribute or join a project team, your workflow needs to change. In this episode, I’ll walk you through the big picture of a contributor’s workflow. Then in the rest of this hands-on coding lab, you and I will walk through each of the steps of how to make a copy, branching, keeping your code up-to-date with the original repository, making a pull request, and more.
You’ve opened a pull request (PR). Let’s walk through a typical code review process. You’ll request 2 changes. Then you’ll walk through making the changes and pushing them to GitHub for further review. Let’s do this together.
Let’s review everything you did in this lab. Then I’m going to challenge you to contribute. Finally, share this lab with others whether on social media, at meetups, or at work. If this lab helped you, share it with your peers.
When you are working in a branch, it’s likely that the develop branch will get new PRs merged into it. When that happens, you might need those changes in your branch in order to complete your work and/or avoid a merge conflict. There are several strategies for keeping your branch up-to-date: Do nothing – when there are no changes that impact you Merge update strategy Rebase update strategy The project or team sets the branching and update strategy. It’s important that you know which strategy they use and then follow it.
It’s time to open a Pull Request (PR) in order to submit your contribution for consideration. Let’s walk through the process and do it together. You’ll also walk through the GitHub interface and explore discussion options, tagging, and code comparisons.
What if you made a commit and then realized that you forgot to make one more change? Imagine that you’d like that change to be packaged up with the last commit, as it all goes together. You could do another commit. But instead, you can amend your last commit and add the new changes to it. Let’s do it together.
Know the Code develops and empowers professional WordPress developers, like you. We help you to grow, innovate, and prosper.