search

greplytix / Hamlbars

Sublime Text 3 Syntax highlighting for .hamlbars files which is a combination of both Haml and Handlebars
MIT License
2 stars 0 forks source link

Create a file, commit, and merge it #7

Closed anthonykulis closed 9 years ago

anthonykulis commented 10 years ago

@jonlegacy To make sure you have a grip on this, I need to branch master, create, add, commit a file named after you, and then merge it back into master. Be sure to clean up your branches when done. Please do this via the shell. We will get into using the app later.

anthonykulis commented 10 years ago

Oh, be sure to close your ticket when done. Also, review github commit messages. You can use things like "#7" in your commit message to link this ticket to the commit. So please include that.

anthonykulis commented 10 years ago

@jonlegacy hey, need you to follow those instructions above and not work off of master exclusively. Reason being, we only merge into master, never commit. This allows us to test our branch for errors and what not and so when we merge it (pull request), we never merge in broken code. So please try it again.

picchietti commented 10 years ago

I was under the impression that I branched master into "temp_jon", moved to temp_jon, added the file to temp_jon, committed temp_jon, then switched to master and merged with temp_jon, then push the changes back to github.

Does this accomplish the same thing as merging with a git pull request? I think the benefit of merging with a git pull request would be that I'm merging my code with the lastest master instead of the master that I have locally?

I'll redo this once I get home, I'm about to give a presentation.

anthonykulis commented 10 years ago

Yes. I probably wasn't too clear here. It was covered on Monday in our meeting. So sorry. We want to branch, do our work, commit, push, and create a pull request. We do our pull request on Github. We do this because Github provides us extra features within the realm of project management that git alone does not.

While you are on your local version, you can branch, commit, and merge as you see fit, but let's not into master. Leave merging into master for Github pull request.

Also realize we can branch off of master and push that up to Github (called publishing). Then we can branch off of that published version do pull requests to that branch we published. Finally when done, we can do a pull request into master. This is how deep in the branch tree I typically go. I create that first initial branch as my "milestone", and branch my tickets for that milestone off of that. My tickets are logically atomic, where Joe and Dan make atomic commits on code features. Either way is reasonable and both have their advantages.