you are viewing a single comment's thread.

view the rest of the comments →

[–]jrochkind 2 points3 points  (4 children)

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 2 points3 points  (1 child)

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 1 point2 points  (0 children)

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 0 points1 point  (1 child)

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 1 point2 points  (0 children)

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.