-
1. Re: Draft github workflow document created
I've also updated the contributing to AeroGear, and jira usage wiki pages to be current. Please take a look at these and let me know if I missed anything or if you have comments?
-
2. Re: Draft github workflow document created
Note that I've also created the AeroGear Licensing and Copyright page and have updated the AeroGear IDE config repo with the correct license and copyright information. Note that these updates are in the aerogear branch, which is now the default branch for that repo.
-
3. Re: Draft github workflow document created
The only one I have not integrated with the branching concepts from Qmx - https://img.skitch.com/20111212-f6qd1bf38ucsw4gb56tcj2j1y3.jpg
Qmx - could you write in this thread how these changes would effect the workflow? Also what would happen when users have overlapping topic branches going at the same time? The image you provided looks very linier. I just want to make sure I understand it better, so we can discuss it.
My suggestion boils down on relaxing the "squash to one commit rule", meaning that it's good to keep history (given that the history is meaningful (usually it is).
About it looking very linier, that's exactly how it should look. Before doing the no-ff merge, you rebase your branch to keep the history linear, and in this case, linear != having no merge commits. I started adopting this practice after suffering to find a regression on a 20-commit-squashed-to-one
-
4. Re: Draft github workflow document created
Douglas Campos wrote:
My suggestion boils down on relaxing the "squash to one commit rule", meaning that it's good to keep history (given that the history is meaningful (usually it is).
I agree with relaxing the "squash to one commit rule" - I think there is some wording around that. I'll update make it clear that your only need to squash trivial commits.
Douglas Campos wrote:
About it looking very linier, that's exactly how it should look. Before doing the no-ff merge, you rebase your branch to keep the history linear, and in this case, linear != having no merge commits. I started adopting this practice after suffering to find a regression on a 20-commit-squashed-to-one
Let me see if I get this one - sorry for seeming dense.
In your situation before merging your topic/pr branch, you rebase to the latest, and then merge to master. This would give you the type of history here - https://img.skitch.com/20111212-f6qd1bf38ucsw4gb56tcj2j1y3.jpg
Each topic branch is isolated until merged, and you have a merge commit?
-
5. Re: Draft github workflow document created
Each topic branch is isolated until merged, and you have a merge commit?
Perfect, that's exactly what I meant
-
6. Re: Draft github workflow document created
Lets get some more feedback on this, but I think this would be good.
Anyone else have thoughts here?