Now that we can manipulate the DOM, it’s time to revisit Rock Paper Scissors and add a simple UI to it.
Before you start making changes to your Rock Paper Scissors project, you need to learn about a concept in Git called branching so that you can make your changes without having to worry about breaking what you have now.
Branches in Git allow your repository to hold multiple alternate reality versions of your files at the same time. You’ve actually (sort of) been using branches since you made your first commit, you just might not have known it! Back in the setting up Git lesson when you ran
git config --global init.defaultBranch main you were setting the name of what’s called the default branch for your repos. The default branch is just what we call the branch that is created when you make your first commit on a project, and in that command we set the name to be
main as is the current standard.
Like the branches in a tree (hence the name), all of the branches for a project stem off of a “trunk” (the
main branch) or off of other branches.
When you make commits on a specific branch those changes only exist on that branch, leaving all of your other branches exactly as they were when you branched off of them.
This means that you can keep your
main branch as a place for only finished features that you know are working properly, and add each feature to your project using dedicated branches which we call feature branches.
You can make new branches by using the command
git branch <branch_name>. You can then change to your new branch using
git checkout <branch_name>. You can also create a new branch and change to it in a single command by using the
-b flag with
checkout, in the form
git checkout -b <branch_name>.
You can see all of your current branches using
git branch with no other arguments. The branch that you’re currently on will be indicated with an asterisk. If you want to change back to
main from any other branch, you can do so just like changing to any other branch using
git checkout main.
Once you’re done working on your feature branch and you’re ready to bring the commits that you’ve made on it to your main branch, you need to perform what is known as a
Merges are done by using the command
git merge <branch_name> which will take the changes you’ve committed in
branch_name and add them to the branch that you’re currently on.
Sometimes the same lines in a file will have been changed by two different branches. When this happens you will have a merge conflict when you try and merge those branches together. In order to finish merging the branches you will have to first resolve the conflict, which will be covered in a future lesson.
When you don’t need a branch anymore it can be deleted using
git branch -d <branch_name> if the branch has already been merged into
main, or with
git branch -D <branch_name> if it hasn’t. You will usually want to delete branches when you’re done with them, otherwise they can pile up and make it more difficult to find the branch you’re looking for when you need it.
Another great use case for branches is to share code with others that you might not want to commit to your main branch (or feature branch) at all.
For example: if you have a bug in a new feature you’re working on that you can’t figure out, and it causes your code to break, you don’t want to commit that broken code and have it in your project’s “permanent record”. Thankfully, branches make it easy to share code on GitHub without having to commit problematic code where it can be seen in the future!
temp) and change to it with
git checkout -b temp
tempbranch like you normally would
tempbranch to your GitHub repo with
git push origin temp
tempbranch using the branch selector dropdown.
git checkout -b rps-ui.
rps-uibranch, locally. However, this branch does not exist in your remote repo yet. If you go to your github repo page, you’ll see that you only have 1 branch, which would be
main. Let’s push this new branch to your remote repo with the command
git push origin rps-ui. Now, you’ll see two branches in your Github repository!
rps-uibranch. You can check this, with the
git branchcommand. The branch you are currently on will have an (*)asterisk next to it. If you’re in another branch for some reason, change to
rps-uiwith the command
git checkout rps-ui. Now you’re all set to work on your new feature! Note: You can add files, commit to this branch, and push changes to your repo, just like you would with the main branch. Everything is the same except when you push the changes, you’d use
git push origin rps-uiinstead of
git push origin main, since we’re pushing to our new branch.
playRoundfunction with the correct
playerSelectionevery time a button is clicked. (you can keep the
console.logs for this step)
divfor displaying results and change all of your
console.logs into DOM methods.
rps-uibranch back to our
mainwith the command
git checkout main.
main, our current branch, with
git merge rps-ui.
rps-uibranch is now successfully merged with main! Use
git logand you’ll see all the commits you’ve made to your feature branch on top of the commits you made to the main branch. Now for our final step!
mainbranch into our remote repo by running
git push origin main. Go to your Github repo and you’ll see that our
mainbranch will have all the changes and commits you made to the
rps-uibranch. Congratulations! You’ve successfully pushed your first feature into your production branch!
rps-uibranch anymore. Let’s do some cleanup, both locally and in the remote repo. Delete the branch from our local repo with
git branch -d rps-uiand also delete it from the remote repo on Github with
git push --delete origin rps-ui. Congrats, we’re all done with our cleanup!
This section contains helpful links to related content. It isn’t required, so consider it supplemental.
git push -u origin <branch>. It automatically links the local branch you push with the remote one. Read this educative.io article by Talha Ashar and commit faster to a remote branch with a simple