[Vm-dev] git mavens, shortcut please?

Ben Coman btc at openinworld.com
Tue Jun 21 12:02:29 UTC 2016

Update for people working from a forked repository...
(btw a tip, try using tab completion for repo names:)

On Mon, Jun 20, 2016 at 1:00 AM, Ben Coman <btc at openinworld.com> wrote:
> On Sun, Jun 19, 2016 at 8:41 AM, tim Rowledge <tim at rowledge.org> wrote:
>> Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works

> 1. Go to https://github.com/OpenSmalltalk/vm

1b. Click the <Fork>  button in the top right.
       You'll then be looking at  https://github.com/YOURNAME/vm

> 2.  Click the green <Clone or download> button.
>      (If you've already set up your SSH keys, click "Use SSH".)
>      then copy the url to the clipboard.
> 3. Clone to your local machine
>     $ git clone #paste-url-from-the-clipboard-here
>     $ cd vm   # or opensmalltalk-vm if official repo is renamed
>     $ git remote -v
> origin git at github.com:OpenSmalltalk/vm.git (fetch)
> origin git at github.com:OpenSmalltalk/vm.git (push)
> or...
> origin https://github.com/OpenSmalltalk/vm.git (fetch)
> origin https://github.com/OpenSmalltalk/vm.git (push)
> ...depending on ssh or https clone respectively

3b. Additionally, set up quick reference to the upstream repository
    $ git remote add OpenSmalltalk https://github.com/OpenSmalltalk/vm
    $ git remote -v
OpenSmalltalk https://github.com/OpenSmalltalk/vm (fetch)
OpenSmalltalk https://github.com/OpenSmalltalk/vm (push)
origin git at github.com:bencoman/vm.git (fetch)
origin git at github.com:bencoman/vm.git (push)

> 4. Create a branch to work on...
>     $ git fetch    #updates all branches to latest
>     $ git checkout -b SomeBug Cog

4. Instead, now do...
    $ git fetch OpenSmalltalk
    $ git checkout -b ABug OpenSmalltalk/Cog
Good to create server repo straight away to avoid later "no upstream
branch" error
    $ git push -u origin
    $ git branch --all   # oldTrunk & plugin branches not shown for clarity
* ABug
  remotes/origin/HEAD -> origin/Cog

> 5. Edit, compile, test cycle.  Commit often along the way.
>     * make required changes
>     $ git stage -u
>     $ git diff ; git diff HEAD
>     $ git commit -m "SomeBug - part way there"
> Repeat as necessary
> 6. Ready to submit.  Clean up *local* history (since we committed quite often)
>     $ git rebase -i    # Squash inconsequential commits. Rebase is
> okay before publishing.
>     Ref: https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/
>             https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview
> 7. Catch up to official Cog branch
>     $ git fetch     # updates origin/*
>     $ git log HEAD..origin/Cog    # review other updates
>     $ git diff origin/Cog   # review other updates
> Depending on whether the final history should be linear (more like SVN??)
>     $ git rebase origin/Cog   # rebase okay since not yet published
> or show the branching...
>    $ get merge origin/Cog
> ...might depend on whether its a small fix or a larger feature added.

7. Instead now do...
    $ git fetch OpenSmalltalk
    $ dit diff OpenSmalltalk/Cog
    $ git rebase OpenSmalltalk/Cog
    $ git merge OpenSmalltalk/Cog

> 8. Submit for review
>     $ git push    # to server
> You will see...
>            fatal: The current branch SomeBug has no upstream branch.
> which is because the SomeBug branch only exists locally, not on the
> github server. The following creates the branch on the "origin" server
> and sets things so subsequently this branch only requires "git push".
>     $ git push --set-upstream origin SomeBug
>     * On github, from the <Branch> pulldown button, select your SomeBug branch.
>     * Click <New pull request> button.  For more detail refer...
>        https://help.github.com/articles/using-pull-requests/
> (In the meantime, work on some other branch)
> 7. Reviewers can download PR to test locally as described here...
> https://help.github.com/articles/checking-out-pull-requests-locally/
> (though I've not done that since I've not been on the receiving side
> of a pull request before)
> 8. Respond to reviewer comments. Edit, compile, test, resubmit.
>     $ git checkout SomeBug
>     * make required changes
>     $ git stage -u
>     $ git commit -m "changed per feedback "
>     $ git push    # Pull request auto updated
> (Repeat as required)
> 9. Pull request acceptable.  Optionally (and some policy discussion
> required) squash changes from review period.
>    $ git rebase -i
>    $ git push -f
> Note this does rewrite the history of the published SomeBug branch,
> but presumably the branch is thrown away after integration so no real
> foul.  But forcing pushing may be risk for accidentally doing it to
> the Cog or master branches.  (btw, has the force protection on those
> two branches been tested?)
> 10. On github, integrator accepts pull request.
> 11. Delete branch.

cheers -ben

More information about the Vm-dev mailing list