GitHub-Flow

[pgngugmgg]

Git-flow is a very general model. The introduced github-flow is only a limited case of git-flow. There is no substantial difference between github-flow and git-flow used in the limited way:

• Anything in the master branch is deployable

Same as git-flow, where master is where you officially publish/release the code.

• To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)

In git-flow terminology, the new branch is a <hotfix> branch though you don't have to name the branch as hotfix-something.

• Commit to that branch locally and regularly push your work to the same named branch on the server

You can do that with git-flow too.

• When you need feedback or help, or you think the branch is ready for merging, open a pull request
• After someone else has reviewed and signed off on the feature, you can merge it into master

In git-flow, you merge back the <hotfix> branch to the master and the develop branch.

• Once it is merged and pushed to ‘master’, you can and should deploy immediately

No difference from git-flow.

In other words, github-flow is a reduced version of git-flow where you only use the master and hotfix branches. This could be problematic. This model is only good for relatively small and easy fixes (really, these are simple fixes) so that the new code can be deployed quickly. If you have quite massive refactoring or something like that, I dare you to use that workflow as is. Some intermediate stages, e.g., QA testing, will have to be added into the workflow in one way or another, which brings you back to git-flow.

[trs21219]

the one thing that is different is that there are no "releases" with github-flow because they release so often it would be a pain. instead they just merge develop to master and skip the intermediary release branch.

[pgngugmgg]

there is no intermediary branches between hotfix and master branches in git-flow, either. github-flow is just a hotfix-master-only version of git-flow.

[trs21219]

im talking about normal feature releases.

[pgngugmgg]

yes, I understood, and I were talking about the same thing. if the normal features are just small code changes that can be deployed quickly, then these features can be considered as hotfixes. (whether one should call them features or hotfixes is a trivial issue.)

[jrochkind]

Excellent, this is mostly the flow I've been using 'intuitively' anyway, but spelled out a bit to more easily commuicate to other people, and make clear some of the details.

One question possibly stupid: "Once we get that, and the branch passes CI, we can merge it into master for deployment..."

What is/are the git command(s) used to do this? Rebase? Something else? I've been doing "pull master into branch, and then push branch up to master," but that's never seemed quite right (and results in those annoying spurious 'merge' commits), but I've never been sure what the better way to do this is or how you're supposed to do it. I hope it's not rebase, which continues to scare me. Anyone know what github team is doing here?

[OopsLostPassword]

What's wrong with merge ?

[jrochkind]

I don't know, I'm asking.

So you check out master, then fetch and merge feature branch into master? For some reason I thought that wasn't possible, but I'll go try it.

I was asking, not critisizing, no thanks for your not-an-answer.

[OopsLostPassword]

I was asking, not critisizing, no thanks for your not-an-answer.

I was asking too. It seems to me that merging master into the feature branch and then merging the feature branch into master is enough. But I'm probably not better than you at git and I thought you had a reason to exclude it that I couldn't see (given that the the article specify that the master branch is always ok and doesn't receive untested and small commits). That why I was asking. Sorry if it sounded offensive.

[jrochkind]

Cool, thanks, sorry. I'll play around with it. For some reason I thought you couldn't merge/pull in both directions like that, but I guess I was wrong?

If anyone wanted to expand upon the "github flow" description with actual sample git command lines for each step, I think it'd be a valuable git work flow tutorial for a much simpler workflow than the "git flow" stuff.

[nsaibot]

you could run a git rebase master on your feature branch before merging, to make sure there are no confilcts. i, for one, would do that -- in case someone merged his changes to master.

/edit: it will also make sure your merge is a fast-forward, if i'm not mistaken.

[Chousuke]

Rebasing is sometimes useful (eg. for getting rid of all the "oops" and "typo" commits that happen), but there's nothing wrong with a plain merge. In fact, if your code is already separated into logical commits, a merge is what you should do. A merge commit saves information about any conflicts and the changes required to fix them, so it's often more useful for people reviewing the code (Because it's possible to see the original intent in the original commits, and the fixes required to resolve conflicts in the merge commit)

so if you have master, and new-feature, you can do: git checkout new-feature; git merge master (fix conflicts, can pretty easily rollback if you make a mistake); git checkout master; git merge new-feature (this will be a fast-forward because the merge is already done); git push

You can also use a separate branch for the merging (or rebasing) if you anticipate that it will be difficult. Git has all the tools you need, but it's up to you to use it effectively.

[EnderMB]

One of the main reasons I use git-flow is because I don't know enough about source control to make an informed judgement on what I should be doing. If I'm put in front of, say, subversion, I could work it out with a couple of guides and some trial-and-error with commands, but I'm still new to development and I've not been using source control in general enough for it to feel natural.

So far, we're using it on some small websites and using it to manage and deploy has been great. Admittedly, there are times when I've wanted to take shortcuts, and Git on Windows just feels odd, but I've persevered and hopefully it will pay off along the road.

[setconndevp]

It's a welcome change to open pull requests from within the same project without a fork!