git flow

[rlskoeser]

add documentation/instructions about using git flow for future development, outside contributors

[rlskoeser]

I've been thinking more about git flow and recognize it probably isn't a good fit for us, because so many of you all use GUIs for your git access, and I think git flow requires command line.

It's probably also not very compatible with the lazy-consensus idea. Perhaps some of the ideas from github flow would work for us? http://scottchacon.com/2011/08/31/github-flow.html

[mialondon]

Something for the call about future work?

[mialondon]

Copying the relevant points from @rlskoeser 's link for discussion:

'So, what is GitHub Flow?

• Anything in the master branch is deployable
• To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
• Commit to that branch locally and regularly push your work to the same named branch on the server
• 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
• Once it is merged and pushed to ‘master’, you can and should deploy immediately'

[moltude]

This looks great and pretty straightforward for those of us who are still new to this whole process. My only question is about merging master back into our local dev-branches if there is a major update to master that we need to integrate into our branch.

edit: 'git rebase master' // this is will solve the question I raised

[rlskoeser]

I think small changes (esp. css/html) generally wouldn't need a separate branch.

I'm not quite clear on what your question is about merging master into a local dev branch? I think it's probably a good idea to merge master into your local branch first (if it's been around long enough / enough changes on master) and do any updates & conflict resolution there before merging back into master.

[rlskoeser]

Also, if you push your dev branch to github (e.g. a few of us collaborating on something), make sure to remove the branch once it's merged back in to master.

[moltude]

Sorry, I edited your comment (didn't realize that was possible!). I think the question I had is answered by rebase.

This example was essentailly the question I had:
http://stackoverflow.com/questions/5340724/get-changes-in-master-into-branch-in-git

[rlskoeser]

I didn't realize it was possible either!

Rebase sounds like the right answer, although I'm not certain it will be available via the git guis some of you use. Hopefully it won't be something we'll have to do often.

[moltude]

Yeah, I think I'm going to give up on the osx gui.. The one for windows was much better and I've found that terminal actually helps me understand the process

[mialondon]

If one of the issues we had this week was pushes overwriting changes made in the interim then I'm all for asking people to merge master locally and checking it before a push back.

[mialondon]

Is the resolution here just to update the documentation and link to it wherever appropriate?

[rlskoeser]

Yes, that sounds right - I think we came to some sort of agreement about what practices we wanted to follow when we last discussed it.

[mialondon]

Are you able to put together some bullet points? I can then test them and tweak as necessary.