Tod/Norbert - I won’t shy away from answering your comments on this - but if its ok - lets move that conversation to a new thread. I don’t want to distract away from how one actually does some form of atomic checkin (and I’m talking a small one - one Smalltalk class, one associated text file).
I earlier tried doing a change on a class - committing, but not pushing and then switching to IntelliJ to then commit and push my config file change - and it didn’t seem to work - which surprised me, so I’m gong to redo my test again with the the latest Iceberg 1.1 in a new image (and also make sure my IntelliJ is attached to the same local repo). This seems like the closest root to how I would like to work (albeit a slightly bit more complicated than I would like, but certainly doable). Tim > On 15 Jun 2018, at 18:26, Todd Blanchard <tblanch...@mac.com> wrote: > > > >> On Jun 15, 2018, at 2:05 AM, Esteban Lorenzano <esteba...@gmail.com >> <mailto:esteba...@gmail.com>> wrote: >> >> >> >>> On 15 Jun 2018, at 10:29, Tim Mackinnon <tim@testit.works >>> <mailto:tim@testit.works>> wrote: >>> >>> >>> In many parts of the dev world - every commit should be shippable, meaning >>> atomic - particularly with the use of CI systems (Travis, Gitlab etc) that >>> build on every commit. >> >> but then, you mean every *push* should be shippable :) >> that’s something I agree :) > > The way we run projects - pushing to master is forbidden. You push your work > to a feature specific branch, a CI server runs all the tests in the branch > every push. We create pull requests from the github project page, people > review them and when the tests are green and reviewers approve, we perform > the merge on github. > > Never touch master (or whatever branch you pick for main trunk) outside of > github. Always perform new work in new branch. >
