Ahahahahahaha. You think that works!<p>No. That fails with the following semi-helpful error message:<p><pre><code>    remote: error: refusing to update checked out branch: refs&#x2F;heads&#x2F;master
    remote: error: By default, updating the current branch in a non-bare repository
    remote: error: is denied, because it will make the index and work tree inconsistent
    remote: error: with what you pushed, and will require &#x27;git reset --hard&#x27; to match
    remote: error: the work tree to HEAD.
    remote: error: 
    remote: error: You can set &#x27;receive.denyCurrentBranch&#x27; configuration variable to
    remote: error: &#x27;ignore&#x27; or &#x27;warn&#x27; in the remote repository to allow pushing into
    remote: error: its current branch; however, this is not recommended unless you
    remote: error: arranged to update its work tree to match what you pushed in some
    remote: error: other way.
    remote: error: 
    remote: error: To squelch this message and still keep the default behaviour, set
    remote: error: &#x27;receive.denyCurrentBranch&#x27; configuration variable to &#x27;refuse&#x27;.
</code></pre>
Actually all of these diagrams for Git need to look substantially more complicated because you first off need to introduce repositories which have a cylinder with a cloud over them (the cloud of course is the staging area) with a sort of recycle-reduce-reuse pattern of arrows `add`, `commit`, `checkout` between these three entities, with the caveat that `checkout` is only kinda-sorta what you&#x27;re looking for with this. In fact there is a cylinder-to-cylinder `pull`-type operation called `fetch`, but `git fetch; git checkout` will not actually update any files, revealing the gaping hole in this simple picture, and you&#x27;ll have to type `git status` to find out that you&#x27;re directed to do a `git pull` anyway, which has to be diagrammed as an arrow pointing from the remote cylinder, bouncing off the local cylinder, and then pointing at the local folder.<p>To get to talk about `push` you then need to introduce the SVN-style &quot;bare repository&quot; in the diagram, a folder-box with the cylinder now drawn large inside it, and explain that this folder exists only to contain the .git subfolder and act as an SVN-style repository. You can then draw `pull` arrows down from it and `push` arrows up to it.<p>Then the workflow is more SVN-style:<p><pre><code>    git branch
    git checkout
    git commit
    git push
    ssh testing-server
    cd git-repository
    git pull
</code></pre>
Now that almost works, except the `git branch; git checkout` flow is not the proper way to push changes in the working directory to the new branch. (The context of the conversation was stuff that was already being developed, presumably on the master branch.) That fails on the checkout with an error message like:<p><pre><code>    error: Your local changes to the following files would be overwritten by checkout:
            foo
            bar
    Please, commit your changes or stash them before you can switch branches.
    Aborting
</code></pre>
But, I mean, close enough. It&#x27;s `git stash branch &lt;newbranch&gt;` and it generates an ugly error message but it does exactly what you want it to do, so you can ignore that error message and hack away.<p>Now, you&#x27;re missing the point if you think &quot;God, drostie is really pedantically getting on my case for missing the remote-repository-update and the git stash here! Anyone will learn that workflow eventually!&quot;<p>The point was not any such thing, the point was <i>clean diagrams</i> when explaining the idea to a fellow developer -- in fact a diagram so clean that a nontechnical user asked about it and accidentally learned enough to get some new vocabulary about how a developer&#x27;s life works, so that they could more effectively communicate what they want to the developer.<p>It is my contention that the git <i>diagram</i>, as opposed to the git <i>workflow</i>, is sufficiently messy that a nontechnical eye will lose curiosity and most certainly will not get the idea of &quot;make a branch, push the branch to the shared repository, then update the testing repository, then switch to that branch, then discard that branch if things don&#x27;t work out.&quot; That strikes me as too in-depth for nontechnical casual users to express.