Some tools you will learn and never have to use. I want to share a quick link on how to view a pull request locally. I found the following gist on how to view a pull request locally. There might be a better way to do this, but I found this to be pretty easy to do.
Starting off you have to make sure you are in the develop/master branch of the project locally(after you have cloned the repo) and run `git fetch.` Fetching will not only pull in the latest commits on the branch but all other branches in the project.
From the command line you will be able to access all pull request using `git checkout pr/<pr #>` and voila, you have access to that pr. Technically you are able to pull the branch the pull request came from also, but I find this easier, since you are looking view those specific changes.
My most recent use for this tool was to review a pull request done by a contractor, there were multiple changes to implement a feature, but it also had multiple errors. I found it nice and east to merge the pull request into my branch and check it out locally. There were multiple conflicts, but it helped me understand what they did as I fixed the changes. If you do not work in a team, I highly recommend joining up with the Odin group and picking up some small task they need done; it a great way to practice some of these concepts.
I am now going to attempt to write test to check their's and my functionality implemented, I do realize I should of wrote test after the merge to check if any of the code actually worked. I came to this realization duding last night's Ruby Dojo, where I was able to practice and view TDD in action. I hope begin writing test first today and help steer myself into writing better Ruby code.
At work TDD is not a requirement, as long as test are written they are cool with it. I also just finished the last chapter of POODR and highly recommend the book for that chapter alone. Its all about testing and testing for the right reasons. I spent 7 minutes in the Dojo testing if an argument returned that argument, which sounds confusing now, because it was and unnecessary. When testing, it should be in small increments and towards the goal of actually solving the problem, not just for the sake of testing (I will walk through this concept in a longer post tomorrow...promise).
Once again, thanks for reading and if you are in the Orlando area, check out the Dojo. Also if you want to read some inspiring post on awesome Ruby concepts check out Ramon's blog. Right now he is going through the book Refactoring Ruby, which has convinced me to put it on my list of books to read.
*If you wan to try the coding exercise yourself, check it out here and let me know how you do. Limit yourself to less than 30minutes and use TDD.
No comments:
Post a Comment