<div dir="ltr">Pushed! The conversion looks really nice!<div><br></div><div>Thanks.</div><div><br></div><div>--joel</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 3, 2018 at 11:12 AM Marçal Comajoan Cara <<a href="mailto:mcomajoancara@gmail.com">mcomajoancara@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Converted <a href="https://devel.rtems.org/wiki/Developer/Git/Users" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Git/Users</a><br>
to Rest, and TBDs and wiki TODOs into comments. Also changed http<br>
links to https (the ones that are possible), corrected typos, updated<br>
learning resources links and added formattings.<br>
<br>
This work was part of GCI 2018.<br>
---<br>
 eng/vc-users.rst | 643 ++++++++++++++++++++++++++++++++++++++++++++++-<br>
 1 file changed, 641 insertions(+), 2 deletions(-)<br>
<br>
diff --git a/eng/vc-users.rst b/eng/vc-users.rst<br>
index ebd79bb..47864b4 100644<br>
--- a/eng/vc-users.rst<br>
+++ b/eng/vc-users.rst<br>
@@ -7,5 +7,644 @@<br>
 Software Development (Git Users)<br>
 ********************************<br>
<br>
-TBD - Convert <a href="https://devel.rtems.org/wiki/Developer/Git/Users" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Git/Users</a> to Rest<br>
-TBD - and insert here.<br>
+.. COMMENT: TBD - Convert <a href="https://devel.rtems.org/wiki/Developer/Git/Users" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Git/Users</a> to<br>
+.. COMMENT: TBD - Rest and insert here.<br>
+<br>
+.. COMMENT: TBD - Managing a (private/public) Git mirror, using GitHub,<br>
+.. COMMENT: TBD - submitting pull requests...<br>
+<br>
+Browse the Git Repository Online<br>
+--------------------------------<br>
+<br>
+You can browse all available repositories online by<br>
+accessing <a href="https://git.rtems.org/" rel="noreferrer" target="_blank">https://git.rtems.org/</a>.<br>
+<br>
+Using the Git Repository<br>
+------------------------<br>
+<br>
+The following examples demonstrate how to use the RTEMS' Git repos. These <br>
+examples are provided for the main rtems module, but they are also valid<br>
+for the other modules.<br>
+<br>
+First, we need to obtain our own local copy of the RTEMS Git repository:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git clone git://<a href="http://git.rtems.org/rtems.git" rel="noreferrer" target="_blank">git.rtems.org/rtems.git</a> rtems<br>
+<br>
+This command will create a folder named rtems in the current directory. This<br>
+folder will contain a full-featured RTEMS' Git repository and the current HEAD<br>
+revision checked out. Since all the history is available we can check out any<br>
+release of RTEMS. Major RTEMS releases are available as separate branches in<br>
+the repo.<br>
+<br>
+To see all available remote branches issue the following command:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git branch -r<br>
+<br>
+We can check out one of those remote branches (e.g. rtems-4.10 branch) using<br>
+the command:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout -b rtems410 origin/4.10<br>
+<br>
+This will create a local branch named "rtems410", containing the rtems-4.10<br>
+release, that will track the remote branch "rtems-4-10-branch" in origin<br>
+(​git://<a href="http://git.rtems.org/rtems.git" rel="noreferrer" target="_blank">git.rtems.org/rtems.git</a>). The ``git branch`` command prints a list of<br>
+the current local branches, indicating the one currently checked out.<br>
+<br>
+If you want to switch between local branches:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout <branch-name><br>
+<br>
+With time your local repository will diverge from the main RTEMS repository. To<br>
+keep your local copy up to date you need to issue:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git pull origin<br>
+<br>
+This command will update all your local branches with any new code revisions<br>
+available on the central repository.<br>
+<br>
+Making Changes<br>
+--------------<br>
+<br>
+Git allows you to make changes in the RTEMS source tree and track those changes<br>
+locally. We recommend you make all your changes in local branches. If you are<br>
+working on a few different changes or a progression of changes it is best to<br>
+use a local branch for each change.<br>
+<br>
+A branch for each change lets your repo's master branch track the upstream<br>
+RTEMS' master branch without interacting with any of the changes you are<br>
+working on. A completed change is emailed to the developer's list for review<br>
+and this can take time. While this is happening the upstream's master branch<br>
+may be updated and you may need to rebase your work and test again if you are<br>
+required to change or update your patch. A local branch isolates a specific<br>
+change from others and helps you manage the process.<br>
+<br>
+First, you need to clone the repository: <br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git clone git://<a href="http://git.rtems.org/rtems.git" rel="noreferrer" target="_blank">git.rtems.org/rtems.git</a> rtems<br>
+<br>
+Or if you already cloned it before, then you might want to update to the latest<br>
+version before making your changes:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  cd rtems<br>
+  git pull<br>
+<br>
+Create a local branch to make your changes in, in this example, the change is<br>
+``faster-context-switch``:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout -b faster-context-switch<br>
+<br>
+Next, make your changes to files. If you add, delete ormove/rename files you<br>
+need to inform Git<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git add /some/new/file<br>
+  git rm /some/old/file<br>
+  git mv /some/old/file /some/new/file<br>
+<br>
+When you're satisfied with the changes you made, commit them (locally)<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git commit -a<br>
+<br>
+The ``-a`` flag commits all the changes that were made, but you can also<br>
+control which changes to commit by individually adding files as you modify<br>
+them by using. You can also specify other options to commit, such as a message<br>
+with the ``-m`` flag.<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git add /some/changed/files<br>
+  git commit<br>
+<br>
+Create a patch from your branch, in this case, we have two commits we want to<br>
+send for review:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git format-patch -2<br>
+<br>
+ There are new changes pushed to the RTEMS' master branch and our local branch<br>
+ needs to be updated:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout master<br>
+  git pull<br>
+  git checkout faster-context-switch<br>
+  git rebase master<br>
+<br>
+Working with Branches<br>
+---------------------<br>
+<br>
+Branches facilitate trying out new code and creating patches.<br>
+<br>
+The previous releases of RTEMS are available through remote branches. To check<br>
+out a remote branch, first query the Git repository for the list of branches:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git branch -r<br>
+<br>
+Then check out the desired remote branch, for example:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout -b rtems410 origin/4.10<br>
+<br>
+Or if you have previously checked out the remote branch then you should see it<br>
+in your local branches:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git branch<br>
+<br>
+You can change to an existing local branch easily:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout rtems410<br>
+<br>
+You can also create a new branch and switch to it:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git branch temporary<br>
+  git checkout temporary<br>
+<br>
+Or more concisely:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout -b temporary<br>
+<br>
+If you forget which branch you are on<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git branch<br>
+<br>
+shows you by placing a * next to the current one.<br>
+<br>
+When a branch is no longer useful you can delete it. <br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout master<br>
+  git branch -d temporary<br>
+<br>
+If you have unmerged changes in the old branch Git complains and you need to<br>
+use ``-D`` instead of ``-d``.<br>
+<br>
+Viewing Changes<br>
+---------------<br>
+<br>
+To view all changes since the last commit:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git diff HEAD<br>
+<br>
+To view all changes between the current branch and another branch, say master:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git diff master..HEAD<br>
+<br>
+To view descriptions of committed changes:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git log<br>
+<br>
+Or view the changeset for some file (or directory): <br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git log /some/file<br>
+<br>
+To view the changesets made between two branches:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git log master..HEAD<br>
+<br>
+Or for a more brief description use shortlog:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git shortlog master..HEAD<br>
+<br>
+Reverting Changes<br>
+-----------------<br>
+<br>
+To remove all (uncommitted) changes on a branch<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout -f<br>
+<br>
+Or to selectively revert (uncommited) files, for example if you<br>
+accidentally deleted ./some/file<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout -- ./some/file<br>
+<br>
+or<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout HEAD ./some/file<br>
+<br>
+To remove commits there are two useful options, reset and revert. ``git reset``<br>
+should only be used on local branches that no one else is accessing remotely.<br>
+``git revert`` is cleaner and is the right way to revert changes that have<br>
+already been pushed/pulled remotely.<br>
+<br>
+git reset<br>
+---------<br>
+<br>
+``git reset`` is a powerful and tricky command that should only be used on<br>
+local (un-pushed) branches): A good description of what it enables to do can be<br>
+found ​here. The following are a few useful examples. Note that adding a ~<br>
+after HEAD refers to the most recent commit, and you can add a number after<br>
+the ~ to refer to commits even further back; HEAD by itself refers to the<br>
+current working directory (changes since the last commit).<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git reset HEAD~<br>
+<br>
+Will undo the last commit and unstage those changes. Your working directory<br>
+will remain the same, therefore a ``git status`` will yield any changes you<br>
+made plus the changes made in your last commit. This can be used to fix the<br>
+last commit. You will need to add the files again. <br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git reset --soft HEAD~<br>
+<br>
+Will just undo the last commit. The changes from the last commit will still be<br>
+staged (just as if you finished git adding them). This can be used to amend the<br>
+last commit (e.g. You forgot to add a file to the last commit).<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git reset --hard HEAD~<br>
+<br>
+Will revert everything, including the working directory, to the previous<br>
+commit. This is dangerous and can lead to you losing all your changes; the<br>
+``--hard`` flag ignores errors.<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git reset HEAD<br>
+<br>
+Will unstage any change. This is used to revert a wrong ``git add``. (e.g. You<br>
+added a file that shouldn't be there, but you haven't 'committed')<br>
+<br>
+Will revert your working directory to a HEAD state. You will lose any change<br>
+you made to files after the last commit. This is used when you just want to<br>
+destroy all changes you made since the last commit.<br>
+<br>
+git revert<br>
+----------<br>
+<br>
+``git revert`` does the same as reset but creates a new commit with the<br>
+reverted changes instead of modifying the local repository directly.<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git revert HEAD<br>
+<br>
+This will create a new commit which undoes the change in HEAD. You will be<br>
+given a chance to edit the commit message for the new commit.<br>
+<br>
+Merging Changes<br>
+---------------<br>
+<br>
+Suppose you commit changes in two different branches, branch1 and branch2,<br>
+and want to create a new branch containing both sets of changes:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout -b merged<br>
+  git merge branch1<br>
+  git merge branch2<br>
+<br>
+Or you might want to bring the changes in one branch into the other:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout branch1<br>
+  git merge branch2<br>
+<br>
+And now that branch2 is merged you might get rid of it:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git branch -d branch2<br>
+<br>
+If you have done work on a branch, say branch1, and have gone out-of-sync<br>
+with the remote repository, you can pull the changes from the remote repo and<br>
+then merge them into your branch:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout master<br>
+  git pull<br>
+  git checkout branch1<br>
+  git merge master<br>
+<br>
+If all goes well the new commits you pulled into your master branch will be<br>
+merged into your branch1, which will now be up-to-date. However, if branch1<br>
+has not been pushed remotely then rebasing might be a good alternative to<br>
+merging because the merge generates a commit.<br>
+<br>
+Rebasing<br>
+--------<br>
+<br>
+An alternative to the merge command is rebase, which replays the changes<br>
+(commits) on one branch onto another. ``git rebase`` finds the common ancestor<br>
+of the two branches, stores each commit of the branch you’re on to temporary<br>
+files and applies each commit in order.<br>
+<br>
+For example<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout branch1<br>
+  git rebase master<br>
+<br>
+or more concisely<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git rebase master branch1<br>
+<br>
+will bring the changes of master into branch1, and then you can fast-forward<br>
+master to include branch1 quite easily<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git checkout master<br>
+  git merge branch1<br>
+<br>
+Rebasing makes a cleaner history than merging; the log of a rebased branch<br>
+looks like a linear history as if the work was done serially rather than in<br>
+parallel. A primary reason to rebase is to ensure commits apply cleanly on a<br>
+remote branch, e.g. when submitting patches to RTEMS that you create by working<br>
+on a branch in a personal repository. Using rebase to merge your work with the<br>
+remote branch eliminates most integration work for the committer/maintainer.<br>
+<br>
+There is one caveat to using rebase: Do not rebase commits that you have pushed<br>
+to a public repository. Rebase abandons existing commits and creates new ones<br>
+that are similar but different. If you push commits that others pull down, and<br>
+then you rewrite those commits with ``git rebase`` and push them up again, the<br>
+others will have to re-merge their work and trying to integrate their work<br>
+into yours can become messy.<br>
+<br>
+Accessing a developer's repository<br>
+----------------------------------<br>
+<br>
+RTEMS developers with Git commit access have personal repositories<br>
+on <a href="https://git.rtems.org/" rel="noreferrer" target="_blank">https://git.rtems.org/</a> that can be cloned to view cutting-edge<br>
+development work shared there.<br>
+<br>
+Creating a Patch<br>
+----------------<br>
+<br>
+Before submitting a patch read about `Contributing<br>
+<<a href="https://devel.rtems.org/wiki/Developer/Contributing" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Contributing</a>>`_ to RTEMS and the<br>
+`Commit Message <<a href="https://devel.rtems.org/wiki/Developer/Git#GitCommits" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Developer/Git#GitCommits</a>>`_<br>
+formatting we require.<br>
+<br>
+The recommended way to create a patch is to branch the Git repository master<br>
+and use one commit for each logical change. Then you can use<br>
+``git format-patch`` to turn your commits into patches and easily submit them.<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git format-patch master<br>
+<br>
+Creates a separate patch for each commit that has been made between the master<br>
+branch and the current branch and writes them in the current directory. Use the<br>
+``-o`` flag to redirect the files to a different directory. <br>
+<br>
+If you are re-submitting a patch that has previously been reviewed, you should<br>
+specify a version number for your patch, for example, use<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git format-patch -v2 ...<br>
+<br>
+to indicate the second version of a patch, ``-v3`` for a third, and so forth.<br>
+<br>
+Patches created using ``git format-patch`` are formatted so they can be emailed<br>
+and rely on having Git configured with your name and email address, for example<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git config --global <a href="http://user.name" rel="noreferrer" target="_blank">user.name</a> "Your Name"<br>
+  git config --global user.email <a href="mailto:name@domain.com" target="_blank">name@domain.com</a><br>
+<br>
+Please use a real name, we do not allow pseudonyms or anonymous contributions.<br>
+<br>
+Submitting a Patch<br>
+------------------<br>
+<br>
+Using ``git send-email`` you can easily contribute your patches. You will need<br>
+to install ``git send-email`` first:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  sudo yum install git-email<br>
+<br>
+or <br>
+<br>
+.. code-block:: shell<br>
+<br>
+  sudo dnf install git-email<br>
+<br>
+or<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  sudo apt install git-email<br>
+<br>
+Then you will need to configure an SMTP server. You could install one on your<br>
+localhost, or you can connect to a mail server such as Gmail.<br>
+<br>
+Configuring git send-email to use Gmail<br>
+---------------------------------------<br>
+<br>
+Configure Git to use Gmail:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git config --global sendemail.smtpserver <a href="http://smtp.gmail.com" rel="noreferrer" target="_blank">smtp.gmail.com</a><br>
+  git config --global sendemail.smtpserverport 587<br>
+  git config --global sendemail.smtpencryption tls<br>
+  git config --global sendemail.smtpuser <a href="mailto:your_email@gmail.com" target="_blank">your_email@gmail.com</a><br>
+<br>
+It will ask for your password each time you use ``git send-email``. Optionally<br>
+you can also put it in your ``git config``:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git config --global sendemail.smtppass your_password<br>
+<br>
+Sending Email<br>
+-------------<br>
+<br>
+To send your patches just<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git send-email /path/to/patch --to <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
+<br>
+To send multiple related patches (if you have more than one commit in your<br>
+branch) specify a path to a directory containing all of the patches created by<br>
+``git format-patch``. ``git send-email`` has some useful options such as:<br>
+<br>
+* ``--annotate`` to show/edit your patch<br>
+* ``--cover-letter`` to prepend a summary<br>
+* ``--cc=<address>`` to cc someone<br>
+<br>
+You can configure the to address:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git config --global <a href="http://sendemail.to" rel="noreferrer" target="_blank">sendemail.to</a> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
+<br>
+So all you need is:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git send-email /path/to/patch<br>
+<br>
+Troubleshooting<br>
+---------------<br>
+<br>
+Some restrictive corporate firewalls block access through the Git protocol<br>
+(​git://). If you are unable to reach the server ​git://<a href="http://git.rtems.org/" rel="noreferrer" target="_blank">git.rtems.org/</a> you can<br>
+try accessing through http. To clone the rtems repository using the http<br>
+protocol use the following command:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git clone <a href="http://git.rtems.org/rtems/" rel="noreferrer" target="_blank">http://git.rtems.org/rtems/</a> rtems<br>
+<br>
+This access through http is slower (way slower!) than through the git protocol,<br>
+therefore, the Git protocol is preferred.<br>
+<br>
+Manage Your Code<br>
+----------------<br>
+<br>
+You may prefer to keep your application and development work in a Git<br>
+repository for all the good reasons that come with version control.<br>
+For public repositories, you may like to try `GitHub <<a href="https://github.com/" rel="noreferrer" target="_blank">https://github.com/</a>>`_<br>
+or `BitBucket <<a href="https://bitbucket.org/" rel="noreferrer" target="_blank">https://bitbucket.org/</a>>`_. RTEMS maintains<br>
+`mirrors on GitHub <<a href="https://github.com/RTEMS" rel="noreferrer" target="_blank">https://github.com/RTEMS</a>>`_ which can make synchronizing<br>
+with upstream changes relatively simple. If you need to keep your work private,<br>
+you can use one of those services with private repositories or manage your own<br>
+server. The details of setting up a server are outside the scope of this<br>
+document, but if you have a server with SSH access you should be able to `find<br>
+instructions<br>
+<<a href="https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server" rel="noreferrer" target="_blank">https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server</a>>`_ on<br>
+how to set up Git access. Once you have git configured on the server, adding<br>
+repositories is a snap.<br>
+<br>
+Private Servers<br>
+---------------<br>
+<br>
+In the following, replace @USER@ with your username on your server, @REPO@ with<br>
+the name of your repository, and @SERVER@ with your server's name or address.<br>
+<br>
+To push a mirror to your private server, first create a bare repository on your<br>
+server.<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  cd /home/@USER@<br>
+  mkdir git<br>
+  mkdir git/@REPO@.git<br>
+  cd git/@REPO@.git<br>
+  git --bare init<br>
+<br>
+Now from your client machine (e.g. your work laptop/desktop), push a git,<br>
+perhaps one you cloned from elsewhere, or one that you made locally with<br>
+``git init``, by adding a remote and pushing:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  git remote add @SERVER@ ssh://@SERVER@/home/@USER@/git/@REPO@.git<br>
+  git push @SERVER@ master<br>
+<br>
+You can replace the @SERVER@ with another name for your remote if you like.<br>
+And now you can push other branches that you might have created. Now you can<br>
+push and pull between your client and your server. Use SSH keys to authenticate<br>
+with your server if you want to save on password typing; remember to put a<br>
+passphrase on your SSH key if there is a risk the private key file might get<br>
+compromised.<br>
+<br>
+The following is an example scenario that might be useful for RTEMS users that<br>
+uses a slightly different approach than the one just outlined:<br>
+<br>
+.. code-block:: shell<br>
+<br>
+  ssh @SERVER@<br>
+  mkdir git<br>
+  git clone --mirror git://<a href="http://git.rtems.org/rtems.git" rel="noreferrer" target="_blank">git.rtems.org/rtems.git</a><br>
+  ## Add your ssh key to ~/.ssh/authorized_keys<br>
+  exit<br>
+  git clone ssh://@SERVER@/home/@USER@/git/rtems.git<br>
+  cd rtems<br>
+  git remote add upstream git://<a href="http://git.rtems.org/rtems.git" rel="noreferrer" target="_blank">git.rtems.org/rtems.git</a><br>
+  git fetch upstream<br>
+  git pull upstream master<br>
+  git push<br>
+  ## If you want to track RTEMS on your personal master branch,<br>
+  ## you should only push changes to origin/master that you pull<br>
+  ## from upstream. The basic workflow should look something like:<br>
+  git checkout master<br>
+  git pull upstream master<br>
+  git push<br>
+  git checkout -b anewbranch<br>
+  ## Repeat: do work, git commit -a<br>
+  git push origin anewbranch<br>
+<br>
+  ## delete a remote branch<br>
+  git push origin :anewbranch<br>
+  ## delete a local branch<br>
+  git branch -d anewbranch<br>
+<br>
+Learn more about Git<br>
+--------------------<br>
+<br>
+Links to the sites with good Git information:<br>
+<br>
+* <a href="http://gitready.com/" rel="noreferrer" target="_blank">http://gitready.com/</a> - An excellent resource from beginner to very advanced. <br>
+* <a href="http://progit.org/book/" rel="noreferrer" target="_blank">http://progit.org/book/</a> - Covers Git basics and some advanced features.<br>
+  Includes some useful workflow examples.<br>
+* <a href="https://lab.github.com/" rel="noreferrer" target="_blank">https://lab.github.com/</a> - Learn to use Git and GitHub while doing a series of<br>
+  projects.<br>
+* <a href="https://git-scm.com/docs" rel="noreferrer" target="_blank">https://git-scm.com/docs</a> - The official Git reference.<br>
-- <br>
2.17.1<br>
<br>
</blockquote></div>