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.
There are times when you are working on changes and then realize, “Whoops, I’m going in the wrong direction.” When that happens, you want to ability to rollback those changes (or some of them) to the previous commit state. How do you do that? Git gives you a command to remove one, some, or all of the changed tracked files. But what if you have new directories and/or files? How do you remove those? Let’s dig into this topic in this episode.
Before we start customizing the theme, we want to store away a snapshot of the original theme. Why? At this point, all we did was git the Twenty Seventeen theme into version control. Nothing has been stored (committed). Therefore, ALL of the theme’s files are new to git. That means it sees all of the files as changed. Okay, but when you go to make your first customizations, you will want to know what was customized. To isolate those changes, you first need to commit the original theme. Let’s talk through this in this episode.
In Simply Git, we covered how to stage all the changes from the working to staging area. Let’s use our new bash function syntax to build an alias that stages all of the changes and then displays the status.
Merge conflicts will happen. Let’s create one together. Then we’ll walk through how to find them and fix them.
In this episode, you and I will walk through the update workflow using the merge strategy. In order to do this, we’ll have to get creative in order to create a situation where the branch you are working on does not have the most recent updates that are in your develop branch. The workflow is: Checkout your develop branch. Pull the latest changes to update that branch. Checkout the change you are working on. Then do a git merge develop to update your branch. When this happens, git will create a “merge commit.” Here, let’s do it together.
I often like to view the last commit’s log in order to remember what happened last. Let me show you how to view that log and then create an alias for it.
In the Simply Git, you learned how to add new changes to your last commit. We can streamline that process to: Add all changes from both the working and staging areas. Keep the last commit message and not pop open the editor. Display the log when we’re done. Let’s build an alias.
In Simply Git, you learned how to fix the last commit message. Let’s build an alias.
Let’s talk about naming strategies for your branches. Hint: Each team and/or project may have its own strategy for naming branches.
In the Git Contributing lab, I had you typing the really long command to view the one-line, decorated, graphical log. It’s one of my favorite commands as it gives you so much valuable information about your project’s history. Typing out that command is time consuming and frankly a waste of your valuable time. You have to try to remember all the options. That takes your focus off of where you add value. Let’s create an alias shortcut to make it so easy.
Know the Code develops and empowers professional WordPress developers, like you. We help you to grow, innovate, and prosper.