Phew - I can confirm that (unsurprisingly I guess) - just committing in Iceberg (without ticking - push changes to origin/master) does then let you easily overlay the same checked out project (typically ./iceberg/ProjectName) in a tool like VSCode or IntelliJ where you can then also commit further changes to files that Iceberg is ignoring (essentially everything not in the src directory - typically candidates would be your Readme.md file and possibly a ./scripts or ./assets directory).
In that other tool you can then issue a push which will then atomically push all commits to a pipeline. It can be a little more tricky to understand what the pipeline is building - in Gitlab it will show you the comment of the most recent commit in the pipeline, however if you then click on the branch the pipeline is running on, you will get a list of commits and can see all the commits that are between the running pipeline and the previously run pipeline. For many of you - this might be pleadingly obvious - but when you have a different workflow mindset in your head, it might be trickier to spot this subtlety. Tim p.s. Thanks for all the useful debate in this thread. I should add that when I wrote “I’ll shut up” - a meant more that I felt the conversation was going in a cycle and repeating itself, not that I was offended or frustrated. I can probably live with the above nuance for my desire for atomic commits. p.p.s It hadn’t occurred to me that the most common use case where people will hit a similar problem to me - is that Readme.md file. Definitely that is one where it should possibly automatically added to the index, or catered for - as it is really just a text file right? > 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. >
