You are right, Peter. But the way the rest of the world (and many people using git from Pharo or other Smalltalk implementations) is that you propose patches which I believe are quite similar to commits. That would be the equivalent of our slice, I guess.
I don't think that slice has equivalence in git, because we have changes much more fine-grained. Git patch is simply a diff between two different versions. And even though github (or bitbucket) offer things like "pull requests", they are only a nicer way of presenting a diff. But this doesn't really matter, because the result will be still the same. Now what might be an interesting work flow would be when an issue is tagged
Fix Review Needed and the CI monkey validates the issue it pushes the slice to a new IssueNNNNN branch in github and branch diff emailed from there.
Unless we want to migrate from fogzbugz to github and do code-reviews there in pull requests there's really no reason to create new branches. You can just create detached commits. (But then again, creating branches is dirt cheap). Actually for a diff you don't need to even commit, because you can compare your current code to the commited one (just like in Monticello). Peter