Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Kevin Korte
28,149 PointsDo you use pull requests on your own repo?
I'm trying to decide how effective this is, I like the paper trail left behind for myself. My thought was to work in a dev branch, reach a production ready point, create the pull request, merge it to master, and than push it into staging --> production as my work flow on a one man repo.
-vs-
just committing to master, than push it to staging --> production.
I'm open to thoughts and options for either side.
3 Answers
Cena Mayo
55,236 PointsMy first reaction is that, for people who are still learning and/or haven't worked in a 'real' development environment, the process you propose is a good way to get used to using git in a more real world fashion. I know that I have a terrible tendency to just push everything to master, which is really not a good way to do things, and frequently results in broken code/wasted time.
Another way to do this is by working on a branch, pulling in master, fixing any errors, then pushing back to master.
Tim Knight
28,888 PointsKevin,
Something like a pull request is actually just a feature created in tools like GitHub it's not something you really have to do especially for your own project. You're definitely thinking the right way though in terms of doing feature branches. So you think of a feature and work on that within a "feature branch", then when it's ready you merge it into the master branch. If you're using something like GitHub, their feature to do release tagging is especially great if you're doing semantic versioning.
Kevin Korte
28,149 PointsSo I've been using git for about 18 months strong now. 99.99% of what I do are on my own repos. I just did my first fork, edit, and pull request on another repo. I was using a Hubot plugin and the author had a spelling error in one of Hubot's responses, so I fixed it and created a pull request for him.
Other than that, I watch and read issues and pull requests on high traffic repos to see the workflow and discussion.
This got me thinking if I was missing something for myself. I did some light reading this morning and the general consensuses on the like of Stack Overflow was it wan't necessary. Wasn't sure if a year from now, I was was going to wish I had done it.
What I do now, is what both of you recommended, I just create feature branches, and eventually merge the branch back into master when I feel it's ready. Might even throw the feature branch up on Heroku to test it in the browser and multiple devices before pushing to master, and than pushing to my heroku production.
Appreciate the responses.