Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Flow

scottchacon.com

Post reply on HN
Print view View original

61–66 of 66 posts

Re: GitHub Flow

#61

Post by tpz »

pgr0ss wrote: post #49
freedrull wrote: post #41

Earlier quoted context omitted.

Learn to use rebase and squash commits! It solves a lot of the issues you talked about.

Squashing commits can fix up git history, but it does not address the bigger issues: refactoring, lack of builds, and having to deploy multiple branches to test features. The first two make it very hard to do any significant code reworking on a feature branch.

I intend no ill will with this response, but it is worth pointing out that "the first two" "bigger issues" have nothing to do with your revision control system.

Lack of builds is something about which you and your CI server need to have a chat, and refactoring is something about which you and your people need to have numerous chats before, during, and afterwards.

Re: GitHub Flow

#62

Post by scorpion032 »

kneath wrote: post #57
simonw wrote: post #55

Question about the chat deploy bot: there are a few lines in there that look like this: hubot deploy github/ghost-down to production Is that deploying a branch directly to production, or does that cause a branch to be merged with master and then master deployed to production? If the former, why deploy a branch directly rather than sticking to the "master is production" idea?

It's deploying a branch to production. If you think about it, this is completely the example of "master is production-ready" idea. We care so much about keeping master deployable, that if we have code that may have issues and need to be rolled back, we deploy just the branch. That way if things break, you can "roll back" to master and everything is good again.

In any case, you can always do a `git co hash`.

Re: GitHub Flow

#63

Post by scorpion032 »

Pewpewarrows wrote: post #6

Very good comparison between workflows of deploying several times per day versus much less often. While it might not be obvious to some, the exact same git "flow" won't work for both. Your tools should complement your corporate culture, not the other way around. I think the most important thing to note from either method, though, is not to develop on master/trunk. Have a separate branch, or further branches off an en…

I typically use master for developing, and another branch called "production" to store whats live.

Re: GitHub Flow

#64

Post by Aqua_Geek »

nosequel wrote: post #46
Aqua_Geek wrote: post #2

I wasn't aware that you can open pull requests from within the same project (i.e. not from a fork). The idea of using this for quick code reviews before merging code into the production branch is really interesting to me...

Most people using github for their everyday work do it the way Scott mentioned. Github's pull request system is fundamental to its success and everyone I know's workflow.

I'm familiar with the Pull Request system. I've just only ever used it to pull changes back into the main repo from other forks; I didn't know you could use them from within the same repo.

Re: GitHub Flow

#65

Post by smalls »

jerhinesmith wrote: post #5

"Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for Jenkins to tell you if it passes everything." From this, it sounds like Jenkins is automatically picking up new topic branches, running the tests, and reporting on the results. Any suggestions on how to set…

I think atmos spills the beans on how their builds with Jenkins work...

https://github.com/atmos/jinkies/wiki/Jenkins-Project-Setup

Post reply on HN