git flow #106

Open
rlskoeser opened this Issue Aug 3, 2013 · 13 comments

Comments

Projects
None yet
3 participants
@rlskoeser

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

@rlskoeser

This comment has been minimized.

Show comment
Hide comment
@rlskoeser

rlskoeser Aug 4, 2013

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

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

This comment has been minimized.

Show comment
Hide comment
@mialondon

mialondon Aug 4, 2013

Contributor

Something for the call about future work?

Contributor

mialondon commented Aug 4, 2013

Something for the call about future work?

@mialondon

This comment has been minimized.

Show comment
Hide comment
@mialondon

mialondon Aug 4, 2013

Contributor

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'
Contributor

mialondon commented Aug 4, 2013

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 comment has been minimized.

Show comment
Hide comment
@moltude

moltude Aug 5, 2013

Contributor

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

Contributor

moltude commented Aug 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@rlskoeser

rlskoeser Aug 5, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@rlskoeser

rlskoeser Aug 5, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@moltude

moltude Aug 5, 2013

Contributor

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

Contributor

moltude commented Aug 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@rlskoeser

rlskoeser Aug 5, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@moltude

moltude Aug 5, 2013

Contributor

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

Contributor

moltude commented Aug 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mialondon

mialondon Aug 5, 2013

Contributor

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.

Contributor

mialondon commented Aug 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mialondon

mialondon Oct 8, 2013

Contributor

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

Contributor

mialondon commented Oct 8, 2013

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

@rlskoeser

This comment has been minimized.

Show comment
Hide comment
@rlskoeser

rlskoeser Oct 8, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@mialondon

mialondon Oct 8, 2013

Contributor

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

Contributor

mialondon commented Oct 8, 2013

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment