The first push should be a:

git push -u origin branchname

That would make sure:

• your local branch has a remote tracking branch of the same name referring an upstream branch in your remote repo 'origin',
• this is compliant with the default push policy 'simple'

Any future git push will, with that default policy, only push the current branch, and only if that branch has an upstream branch with the same name.
that avoid pushing all matching branches (previous default policy), where tons of test branches were pushed even though they aren't ready to be visible on the upstream repo.

Git is like Unix. It is user-friendly, but it is picky about its friends. It's about as powerful and as user-friendly as a shell pipeline.

That being said, once you understand its paradigms and concepts, it has the same Zenlike clarity that I've come to expect from Unix command-line tools. You should consider taking some time off to read one of the many good Git tutorials available online. The Pro Git book is a good place to start.

To answer your first question.

1. What is git remote add ...?

   As you probably know, Git is a distributed version control system. Most operations are done locally. To communicate with the outside world, Git uses what are called "remotes". These are repositories other than the one on your local disk which you can push your changes into (so that other people can see them) or pull from (so that you can get others changes). The command git remote add origin [email protected]:peter/first_app.git creates a new remote called origin located at [email protected]:peter/first_app.git. Once you do this, in your push commands, you can push to origin instead of typing out the whole URL.

2. What is git push origin master?

   This is a command that says "push the commits in the local branch named master to the remote named origin". Once this is executed, all the stuff that you last synchronised with origin will be sent to the remote repository and other people will be able to see them there.

Now about transports (i.e., what git://) means. Remote repository URLs can be of many types (file://, https://, etc.). Git simply relies on the authentication mechanism provided by the transport to take care of permissions and stuff. This means that for file:// URLs, it will be Unix file permissions, etc. The git:// scheme is asking Git to use its own internal transport protocol, which is optimised for sending Git changesets around. As for the exact URL, it's the way it is because of the way GitHub has set up its Git server.

Now the verbosity. The command you've typed is the general one. It's possible to tell Git something like "the branch called master over here is local mirror of the branch called foo on the remote called bar". In Git speak, this means that master tracks bar/foo. When you clone for the first time, you will get a branch called master and a remote called origin (where you cloned from) with the local master set to track the master on origin.

Once this is set up, you can simply say git push and it'll do it. The longer command is available in case you need it (e.g., git push might push to the official public repository and git push review master can be used to push to a separate remote which your team uses to review code). You can set your branch to be a tracking branch using the --set-upstream option of the git branch command.

I've felt that Git (unlike most other applications I've used) is better understood from the inside out. Once you understand how data is stored and maintained inside the repository, the commands and what they do become crystal clear. I do agree with you that there's some elitism amongst many Git users, but I also found that with Unix users once upon a time, and it was worth ploughing past them to learn the system. Good luck!

git has a concept of "remotes" - these are like easy nicknames for a repository, so you don't have to use its full URL every time you want to refer to another repository.

origin is just a remote like any other, but you see it very frequently since when you clone a repository for the first time, git clone will by default set up a remote called origin to refer to the URL that you cloned from.

If you do git remote -v that will show you all the remotes you have set up in your local repository, and the URLs that they refer to. (You'll see that it's a bit more complex than I said above, in that a remote can refer to a different URL for pushing and fetching, but you probably don't need to worry about that. :))

The key is "argument-less git-pull". When you do a git pull from a branch, without specifying a source remote or branch, git looks at the branch.<name>.merge setting to know where to pull from. git push -u sets this information for the branch you're pushing.

To see the difference, let's use a new empty branch:

$ git checkout -b test

First, we push without -u:

$ git push origin test
$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch.test.merge' in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details.

If you often merge with the same branch, you may want to
use something like the following in your configuration file:

    [branch "test"]
    remote = <nickname>
    merge = <remote-ref>

    [remote "<nickname>"]
    url = <url>
    fetch = <refspec>

See git-config(1) for details.

Now if we add -u:

$ git push -u origin test
Branch test set up to track remote branch test from origin.
Everything up-to-date
$ git pull
Already up-to-date.

Note that tracking information has been set up so that git pull works as expected without specifying the remote or branch.

Update: Bonus tips:

• As Mark mentions in a comment, in addition to git pull this setting also affects default behavior of git push. If you get in the habit of using -u to capture the remote branch you intend to track, I recommend setting your push.default config value to upstream.
• git push -u <remote> HEAD will push the current branch to a branch of the same name on <remote> (and also set up tracking so you can do git push after that).