Витание в облаках... установка и первые шаги с GitHub ... а как работать с нескольких компьютеров с разными OS?

Это второй пост, который я пишу с компьютера с ОS Debian... Именно этот дистрибутив я запустил вчера с USB Stick и проверил в режиме persistence. Именно IPython я поставил с помощью apt get ... и был счастлив, когда после перезагрузки "ipython notebook" нашелся и запустился (об этом предыдущий пост). Во второй части поста я создал свой репозитоий на GitHub, потом попробовал его синхронизировать с локальным Debian..., сразу не получлось, пришлось смотреть видео... Потом я еще три дня читал книгу Последняя версия перевода книги за 24.03.2013 доступна в форматах pdf, epub и mobi.

. А здесь получилась запись моего процесса обучения... это первая попытка создать elog (так что сразу можно перейти сюдаКак я бросил все и стал читать книжки PRO GIT... и придумал три классификатора).
Очевидно, что радоваться рано. Полагаю, что гений Билла Гейтс заключается в том, что никто пока не научился обслуживать "инфраструктуру" (стек рабочих программ), лучше, чем Microsoft.
Воспользуемся стандартами Microsoft и оценим риски (для начала).

Вероятность "поломки" флешки¶

Как обновляется Windows все знают, но никто не замечает. Я заметил, насколько хорошо у них все происходит, после того, как начал использовать и обновлять Centos. Первый сбой загрузки после обновления - "kernel panic" испугал и отнял довольно много времени. Тогда я решил не биться головой в стену, а просто "откатить" и работать на старой загрузке... При очередном обновлении все было исправлено. Я тогда понял, почему в меню загрузки выскакивает сразу с десяток предыдущих вариантов. Однако, эта проблема стала возникать все чаще... В конце концов и новый релиз Centos 6.3 надо было переустанвливать, и старый 5.9.. уверенно выдавал "kernel panic" при каждом обновлении...
А оно мне надо было? Залезать в глубины... По сути, перустанавливать вторую OS (первая - Windows). Да еще и специализированные дистрибутивы нашлись... штук 100 ... И стал я плодить флешки... Попробовал, антивирусы, SL-63 работает...
Получается "дешево и сердито" - юзать сразу несколько специализированных дистрибутивов... пока не нашелся "любимый"... Но не тут-то было, дистрибутивы появляются раньше, чем успеваешь завести "серьезные отношения". Тем более, что windows пока "закрывает" большинство задач...
Так появляется мечта "bootable USB persistence". И вот мечта реализована, и теперь надо ставить, доустанавливать... и обновлять софт не на винчестер, а на флешку.

USB перестанет загружаться, Перестанет работать Persistence,
Переполнение..., Данные не идентифицируются,
"Забыто" какие пакеты установлены...

Очевидно, что "поломать флешку" проще всего механически, а потому проще всего было бы где-то хранить резервную копию..., но форматирование раздела persistence ext4, его еще и windows не читает....

...Полезное это дело, думать о рисках... Но спешить не будем. Обратимся к текущим проблемам.
Как мне опубликоать этот пост в блоге? Конвертера не видать, однако... Пока ясно, что можно портрить время на утановку nbconvert на linux (напомню, что в последних версиях эта утилита етсть, а в "устаревших" ее надо доустанавливать... Знакомая картина? Еще бы, это безусловно "лишняя работа"... а можно прямо сейчас начать устанавливать и осваивать GitHub... Это работа, котрую обязательно надо сделать...
Так что займемся освоением GitHub

Настраиваем работу с GitHub вот по этим двум руководствам:¶

Очевидно, что код лучше держать на GitHub How To Install Git on Debian 7. И есть рекомендации, как это лучше делкть How To Use Git Effectively.
Пробовать надо в любом случае. Но надо составить какой-то план обучения... Но как? Самым естественным представляется подход AGILE. Есть некая "генеральная линия", выскакивающие вопросы записываются на стенку... Пожалуй, это надо проверить...

Просто устанавливаем Git on Debian 7¶

In []:

root@kali:~# sudo apt-get install git-core
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  git-core
0 upgraded, 1 newly installed, 0 to remove and 151 not upgraded.
Need to get 1,336 B of archives.
After this operation, 21.5 kB of additional disk space will be used.
Get:1 http://http.kali.org/kali/ kali/main git-core all 1:1.7.10.4-1+wheezy1 [1,336 B]
Fetched 1,336 B in 0s (1,713 B/s)     
Selecting previously unselected package git-core.
(Reading database ... 355615 files and directories currently installed.)
Unpacking git-core (from .../git-core_1%3a1.7.10.4-1+wheezy1_all.deb) ...
Setting up git-core (1:1.7.10.4-1+wheezy1) ...
root@kali:~# 

После установки не грех проверить, что мы установили:

In [1]:

!git help

usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]

           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]

           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]

           [-c name=value] [--help]

           <command> [<args>]



The most commonly used git commands are:

   add        Add file contents to the index

   bisect     Find by binary search the change that introduced a bug

   branch     List, create, or delete branches

   checkout   Checkout a branch or paths to the working tree

   clone      Clone a repository into a new directory

   commit     Record changes to the repository

   diff       Show changes between commits, commit and working tree, etc

   fetch      Download objects and refs from another repository

   grep       Print lines matching a pattern

   init       Create an empty git repository or reinitialize an existing one

   log        Show commit logs

   merge      Join two or more development histories together

   mv         Move or rename a file, a directory, or a symlink

   pull       Fetch from and merge with another repository or a local branch

   push       Update remote refs along with associated objects

   rebase     Forward-port local commits to the updated upstream head

   reset      Reset current HEAD to the specified state

   rm         Remove files from the working tree and from the index

   show       Show various types of objects

   status     Show the working tree status

   tag        Create, list, delete or verify a tag object signed with GPG



See 'git help <command>' for more information on a specific command.

Теперь повторим все, как здесь How To Use Git Effectively

In [3]:

# The first thing we need to do is create our workspace environment: 
!mkdir -p ~/git/testing ; cd ~/git/testing

Первая часть команды была выполнена, библиотека была сделана, но перехода в нее не было... И потом я попытался сменить директорию - ничего не получилось... По-видимому, работает защита...

In [4]:

!pwd

/home/root/ipython

In [5]:

!cd ~/git/testing

In [7]:

!ls

2_github.ipynb first_kali_debian.ipynb

Поскольку директорию поменять не удалось, то пришлось дальнейшие команды выполнять из консоли:

In []:

# We are going to create a test file to use in our repository: 
!touch file

Забыл я про touch Эта команда создает пустой файл. В /root/git/testing появился файл file (текстовый без расширения... естественно)

Итак, мы создали директорию проекта git/testing , потом (в консоли) файл file. Теперь нам эту папку с файлом надо бы синхронизировать с серврером, но сначала создается структура папок в локальном компьютере (init Create an empty git repository or reinitialize an existing one):

In []:

# Вот копия "git init" из моей консоли
root@kali:~/git/testing# git init
Initialized empty Git repository in /root/git/testing/.git/

Отметим, что структура папок репозитория довольно сложна, и в нее надо добавить существующие файлы

In []:

# do not forget about dot after "git add ."

root@kali:~/git/testing# git add
Nothing specified, nothing added.
Maybe you wanted to say 'git add .'?
root@kali:~/git/testing# git add .
root@kali:~/git/testing# 

In []:

#Every time you add or make changes to files, you need to write a commit message
#Commit messages are generally rather short, between one and two sentences explaining what your change did. 

Creating a commit message¶

In []:

root@kali:~/git/testing# git commit -m "Initial Commi_1t" -a
[master (root-commit) 727d1db] Initial Commi_1t
 Committer: root <root@localhost.localdomain>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

    git config --global user.name "Your Name"
    git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

    git commit --amend --reset-author

 0 files changed
 create mode 100644 file
 create mode 100644 help
root@kali:~/git/testing# 

There are two important parameters of the above command. The first is -m, which signifies that our commit message (in this case "Initial Commit") is going to follow. Secondly, the -a signifies that we want our commit message to be applied to all added or modified files.
This is okay for the first commit, but generally you should specify the individual files or directories that we want to commit. We could have also done:

In []:

root@kali:~/git/testing# git commit -m "Initial Commit_2" file
# On branch master
nothing to commit (working directory clean)

To specify a particular file to commit. To add additional files or directories, you just add a space separated list to the end of that command.

Pushing changes to a remote server¶

Up until this point, we have done everything on our local server. ...If you want to work with a team of developers, however, you're going to need to push changes to a remote server.

In []:

root@kali:~/git/testing# git remote add origin https://github.com/apython/forblog.git

После попытки обновления выскочили страшные ошибки насчет отсутствия у меня email. Попробова выполнить рекомендации Why are my commits linked to the wrong user?. Установил (через консоль) параметр:

In []:

git config --global user.email "c131mai@gmail.com"

Потом удостоверился, что параметр появился

In []:

root@kali:~/git/testing# git config -l
user.email=c131mai@gmail.com
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=https://github.com/apython/forblog.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

In []:

Потом дочитал статью. Установил публичный e-mai, и в конце прочитал, что если этот e-mail вы использовали для другого аккаунта, то вас могут и поэтому обругать...
А у меня на другом аккаунте какой e-mail?
Словом, для начала слишком много информации, пока вроде бы все работает, потому здесь распечатаеа еще вот эту справку из консоли.

In []:

root@kali:~/git/testing# git config
usage: git config [options]

Config file location
    --global              use global config file
    --system              use system config file
    --local               use repository config file
    -f, --file <file>     use given config file

Action
    --get                 get value: name [value-regex]
    --get-all             get all values: key [value-regex]
    --get-regexp          get values for regexp: name-regex [value-regex]
    --replace-all         replace all matching variables: name value [value_regex]
    --add                 adds a new variable: name value
    --unset               removes a variable: name [value-regex]
    --unset-all           removes all matches: name [value-regex]
    --rename-section      rename section: old-name new-name
    --remove-section      remove a section: name
    -l, --list            list all
    -e, --edit            opens an editor
    --get-color <slot>    find the color configured: [default]
    --get-colorbool <slot>
                          find the color setting: [stdout-is-tty]

Type
    --bool                value is "true" or "false"
    --int                 value is decimal number
    --bool-or-int         value is --bool or --int
    --path                value is a path (file or directory name)

Other
    -z, --null            terminate values with NUL byte
    --includes            respect include directives on lookup

In []:

root@kali:~/git/testing# git push
Username for 'https://github.com': apython
Password for 'https://apython@github.com': 
To https://github.com/apython/forblog.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/apython/forblog.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
root@kali:~/git/testing# git push --help

In []:

GIT-PUSH(1)                       Git Manual                       GIT-PUSH(1)

NAME
       git-push - Update remote refs along with associated objects

SYNOPSIS
       git push [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<gi
t-receive-pack>]
                  [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose
] [-u | --set-upstream]
                  [<repository> [<refspec>...]]

DESCRIPTION
       Updates remote refs using local refs, while sending objects necessary
       to complete the given refs.

       You can make interesting things happen to a repository every time you
       push into it, by setting up hooks there. See documentation for git-
       receive-pack(1).

OPTIONS
       <repository>
           The "remote" repository that is destination of a push operation.
           This parameter can be either a URL (see the section GIT URLS below)
           or the name of a remote (see the section REMOTES below).

       <refspec>...
           The format of a <refspec> parameter is an optional plus +, followed
           by the source ref <src>, followed by a colon :, followed by the
           destination ref <dst>. It is used to specify with what <src> object
           the <dst> ref in the remote repository is to be updated.

           The <src> is often the name of the branch you would want to push,
           but it can be any arbitrary "SHA-1 expression", such as master~4 or
           HEAD (see gitrevisions(7)).

           The <dst> tells which ref on the remote side is updated with this
 Manual page git-push(1) line 1 (press h for help or q to quit)

Вот онлайн книги и справочники¶

Вот руководство с Debian
Вот хорошая но старая статья на Хабре
Вот вся справка online
Вот книга (онлайн) The entire Pro Git book, written by Scott Chacon and published by Apress, is available here

В голове каша. Поэтому надо найти хорошее видео и все разложить по полочкам¶

Это видео оказалось очень удачным. В сочетании со справкой онлайн быстро разбираешь все команды. И понимаешь логику (последовательность процессов и команд). Во второй части есть упоминание о GitK... Просто повторяем все вслед за автором видео

In []:

root@kali:~/git/testing# git status
# On branch master
nothing to commit (working directory clean)
# в моем локальном репозитории нет новых файлов (хотя их там старых уже штуки три)

Создаем файл и снова запрашиваем статус:

In []:

root@kali:~/git/testing# touch help2
root@kali:~/git/testing# git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# help2
nothing added to commit but untracked files present (use "git add" to track)
root@kali:~/git/testing# 

Для чего я выполняю add? Чтобы начать отслеживать ...в локальном (?) репозитории? Снова запросим статус, он изменился!

In []:

root@kali:~/git/testing# git add help2
root@kali:~/git/testing# git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# new file:   help2
#
root@kali:~/git/testing# 

А теперь отредактируем (изменим содержание) файл и снова запросим статус:

In []:

root@kali:~/git/testing# leafpad help2
root@kali:~/git/testing# git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# new file:   help2
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified:   help2
#
root@kali:~/git/testing# 

Так, каждый раз запрашивая статус, можно понять, как реализована главная идея хранилищ. На локальном компьютере может быть несколько юзеров, потому в локальном хранилище хранятся предыдущие версии, каждый новый вариант можно либо принять (add), либо "откатить" файл к старому варианту (checkout)

А вот второе видео, внизу краткое содержание¶

Today we go over your repositories history using the following commands:
git log
git reflog
git show
gitk
git checkout filename
git reset
Learn how to check your history and revert backwards! At the end of this video I wanted to mention once again that branching is a more efficient want to tackle any crazy "experiments" you'd like to do with your project. There are also other great reasons to branch your project, and I'm pretty excited to make this video hopefully very soon because I know it can be an intimidating subject. Have a great one everybody.
Like colors? Try: git config color.ui true

Перед просмотром запрашиваем статус нашего локального репозитория и оказывается, что там есть новая редакция файла:

In []:

root@kali:~/git/testing# git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified:   github_2.ipynb
#
no changes added to commit (use "git add" and/or "git commit -a")
root@kali:~/git/testing# 

In []:

# Пробуем команду отмены изменений

root@kali:~/git/testing# git checkout -- github_2.ipynb
root@kali:~/git/testing# git status
# On branch master
nothing to commit (working directory clean)
root@kali:~/git/testing# 

Отменили изменения, теперь можно приступить к изучению видеоролика. Здесь речь о "commit", это "точки восстановления ?", создаются при помощи специальной команды. И логируются в хронолоическом порядке... Здесь видно, был изменен еще и e-mail (см. выше):

In []:

root@kali:~/git/testing# git log
commit 94eefc65cd7d1f719fda631794780bc370fce0a6
Author: root <c131mai@gmail.com>
Date:   Tue Mar 18 23:14:12 2014 +0400

    added help2 during video

commit bb6ef33a3a1673f8ce98e3354eb67bff48255ba9
Author: root <c131mai@gmail.com>
Date:   Tue Mar 18 17:56:16 2014 +0400

    ipynb___2

commit 727d1db223ae8961dfd6e6d21b3046ed85a218d4
Author: root <root@localhost.localdomain>
Date:   Tue Mar 18 15:37:51 2014 +0400

    Initial Commi_1t
root@kali:~/git/testing# 

In []:

# При большом количестве участников/исправлений лучше использовать reflog
root@kali:~/git/testing# git reflog
94eefc6 HEAD@{0}: commit: added help2 during video
bb6ef33 HEAD@{1}: commit: ipynb___2
727d1db HEAD@{2}: commit (initial): Initial Commi_1t
root@kali:~/git/testing# 

Можно показать подробности текущего состояния и последнего изменения:

In []:

root@kali:~/git/testing# git show
commit 94eefc65cd7d1f719fda631794780bc370fce0a6
Author: root <c131mai@gmail.com>
Date:   Tue Mar 18 23:14:12 2014 +0400

    added help2 during video

diff --git a/help2 b/help2
new file mode 100644
index 0000000..274c005
--- /dev/null
+++ b/help2
@@ -0,0 +1 @@
+1234
\ No newline at end of file
# ..................
# Use useful option -h
root@kali:~/git/testing# git show -h
usage: git log [<options>] [<since>..<until>] [[--] <path>...]
   or: git show [options] <object>...

    --quiet               suppress diff output
    --source              show source
    --decorate[=...]      decorate options

root@kali:~/git/testing# 

In []:

#На 3:50 секунде видео я научился раскрашивать вывод строк в консоли
root@kali:~/git/testing# git config color.ui true

In []:

# А на 4:40 нашел (и установил) через загрузчик, а потом запустил
root@kali:~# cd home/git/testing
bash: cd: home/git/testing: No such file or directory
root@kali:~# cd git/testing
root@kali:~/git/testing# gitk

Теперь можно смело переходить к commit. На 6:40 секунде автор внес изменения в файл, потом не добавил эти изменения (add)... и начал экспериментировать с commit... Я тоже добавил строчку в свой файл help2 и получил тот же ответ на запрос о статусе:

In []:

root@kali:~/git/testing# leafpad help2
root@kali:~/git/testing# git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified:   help2
#
no changes added to commit (use "git add" and/or "git commit -a")

In []:

# Но сначала распечатаем краткую справку по commit
root@kali:~/git/testing# git commit -h
usage: git commit [options] [--] <filepattern>...

    -q, --quiet           suppress summary after successful commit
    -v, --verbose         show diff in commit message template

Commit message options
    -F, --file <file>     read message from file
    --author <author>     override author for commit
    --date <date>         override date for commit
    -m, --message <message>
                          commit message
    -c, --reedit-message <commit>
                          reuse and edit message from specified commit
    -C, --reuse-message <commit>
                          reuse message from specified commit
    --fixup <commit>      use autosquash formatted message to fixup specified commit
    --squash <commit>     use autosquash formatted message to squash specified commit
    --reset-author        the commit is authored by me now (used with -C/-c/--amend)
    -s, --signoff         add Signed-off-by:
    -t, --template <file>
                          use specified template file
    -e, --edit            force edit of commit
    --cleanup <default>   how to strip spaces and #comments from message
    --status              include status in commit message template
    -S, --gpg-sign[=<key id>]
                          GPG sign commit

Commit contents options
    -a, --all             commit all changed files
    -i, --include         add specified files to index for commit
    --interactive         interactively add files
    -p, --patch           interactively add changes
    -o, --only            commit only specified files
    -n, --no-verify       bypass pre-commit hook
    --dry-run             show what would be committed
    --short               show status concisely
    --branch              show branch information
    --porcelain           machine-readable output
    -z, --null            terminate entries with NUL
    --amend               amend previous commit
    --no-post-rewrite     bypass post-rewrite hook
    -u, --untracked-files[=<mode>]
                          show untracked files, optional modes: all, normal, no. (Default: all)

root@kali:~/git/testing# 

Повторили вслед за роликом (7:00) commit, а потом git push ...И опять у меня ошибка, пожалуй надо ей заняться отдельно

In []:

root@kali:~/git/testing# git commit -am "code that does not work"
[master 0035e42] code that does not work
 1 file changed, 2 insertions(+), 1 deletion(-)
root@kali:~/git/testing# git push
Username for 'https://github.com': apython
Password for 'https://apython@github.com': 
To https://github.com/apython/forblog.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/apython/forblog.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
root@kali:~/git/testing# 

надо бы распечатать справку... Там слишком много текста, потому вывведем все в файл help (он у нас пустует), откроем его в редакторе:

In []:

root@kali:~/git/testing# git push --help > help
root@kali:~/git/testing# leafpad help

А теперь просто скопируем сюда фрагмент текста 'Note about fast-forwards' (надо бы это сделать в консоли, но не хочу отвлекатся...)

In []:

NOTE ABOUT FAST-FORWARDS
       When an update changes a branch (or more in general, a ref) that used
       to point at commit A to point at another commit B, it is called a
       fast-forward update if and only if B is a descendant of A.

       In a fast-forward update from A to B, the set of commits that the
       original commit A built on top of is a subset of the commits the new
       commit B builds on top of. Hence, it does not lose any history.

       In contrast, a non-fast-forward update will lose history. For example,
       suppose you and somebody else started at the same commit X, and you
       built a history leading to commit B while the other person built a
       history leading to commit A. The history looks like this:

                 B
                /
            ---X---A


       Further suppose that the other person already pushed changes leading to
       A back to the original repository you two obtained the original commit
       X.

       The push done by the other person updated the branch that used to point
       at commit X to point at commit A. It is a fast-forward.

       But if you try to push, you will attempt to update the branch (that now
       points at A) with commit B. This does not fast-forward. If you did so,
       the changes introduced by commit A will be lost, because everybody will
       now start building on top of B.

       The command by default does not allow an update that is not a
       fast-forward to prevent such loss of history.

       If you do not want to lose your work (history from X to B) nor the work
       by the other person (history from X to A), you would need to first
       fetch the history from the repository, create a history that contains
       changes done by both parties, and push the result back.

       You can perform "git pull", resolve potential conflicts, and "git push"
       the result. A "git pull" will create a merge commit C between commits A
       and B.

                 B---C
                /   /
            ---X---A


       Updating A with the resulting merge commit will fast-forward and your
       push will be accepted.

       Alternatively, you can rebase your change between X and B on top of A,
       with "git pull --rebase", and push the result back. The rebase will
       create a new commit D that builds the change between X and B on top of
       A.

                 B   D
                /   /
            ---X---A


       Again, updating A with this commit will fast-forward and your push will
       be accepted.

       There is another common situation where you may encounter
       non-fast-forward rejection when you try to push, and it is possible
       even when you are pushing into a repository nobody else pushes into.
       After you push commit A yourself (in the first picture in this
       section), replace it with "git commit --amend" to produce commit B, and
       you try to push it out, because forgot that you have pushed A out
       already. In such a case, and only if you are certain that nobody in the
       meantime fetched your earlier commit A (and started building on top of
       it), you can run "git push --force" to overwrite it. In other words,
       "git push --force" is a method reserved for a case where you do mean to
       lose history.

EXAMPLES
       git push
           Works like git push <remote>, where <remote> is the current
           branch’s remote (or origin, if no remote is configured for the
           current branch).

       git push origin
           Without additional configuration, works like git push origin :.

           The default behavior of this command when no <refspec> is given can
           be configured by setting the push option of the remote.

           For example, to default to pushing only the current branch to
           origin use git config remote.origin.push HEAD. Any valid <refspec>
           (like the ones in the examples below) can be configured as the
           default for git push origin.

       git push origin :
           Push "matching" branches to origin. See <refspec> in the OPTIONS
           section above for a description of "matching" branches.

       git push origin master
           Find a ref that matches master in the source repository (most
           likely, it would find refs/heads/master), and update the same ref
           (e.g.  refs/heads/master) in origin repository with it. If master
           did not exist remotely, it would be created.

       git push origin HEAD
           A handy way to push the current branch to the same name on the
           remote.

       git push origin master:satellite/master dev:satellite/dev
           Use the source ref that matches master (e.g.  refs/heads/master) to
           update the ref that matches satellite/master (most probably
           refs/remotes/satellite/master) in the origin repository, then do
           the same for dev and satellite/dev.

       git push origin HEAD:master
           Push the current branch to the remote ref matching master in the
           origin repository. This form is convenient to push the current
           branch without thinking about its local name.

       git push origin master:refs/heads/experimental
           Create the branch experimental in the origin repository by copying
           the current master branch. This form is only needed to create a new
           branch or tag in the remote repository when the local name and the
           remote name are different; otherwise, the ref name on its own will
           work.

       git push origin :experimental
           Find a ref that matches experimental in the origin repository (e.g.
           refs/heads/experimental), and delete it.

       git push origin +dev:master
           Update the origin repository’s master branch with the dev branch,
           allowing non-fast-forward updates.  This can leave unreferenced
           commits dangling in the origin repository.  Consider the following
           situation, where a fast-forward is not possible:

                           o---o---o---A---B  origin/master
                                    \
                                     X---Y---Z  dev

           The above command would change the origin repository to

                                     A---B  (unnamed branch)
                                    /
                           o---o---o---X---Y---Z  master

           Commits A and B would no longer belong to a branch with a symbolic
           name, and so would be unreachable. As such, these commits would be
           removed by a git gc command on the origin repository.

GIT
       Part of the git(1) suite



Git 1.7.10.4                      11/24/2012                       GIT-PUSH(1)

И все это не помогает, от отчаяния распечатаем еще одну справку:

In []:

root@kali:~/git/testing#  git branch -h
usage: git branch [options] [-r | -a] [--merged | --no-merged]
   or: git branch [options] [-l] [-f] <branchname> [<start-point>]
   or: git branch [options] [-r] (-d | -D) <branchname>...
   or: git branch [options] (-m | -M) [<oldbranch>] <newbranch>

Generic options
    -v, --verbose         show hash and subject, give twice for upstream branch
    -t, --track           set up tracking mode (see git-pull(1))
    --set-upstream        change upstream info
    --color[=<when>]      use colored output
    -r, --remotes         act on remote-tracking branches
    --contains <commit>   print only branches that contain the commit
    --abbrev[=<n>]        use <n> digits to display SHA-1s

Specific git-branch actions:
    -a, --all             list both remote-tracking and local branches
    -d, --delete          delete fully merged branch
    -D                    delete branch (even if not merged)
    -m, --move            move/rename a branch and its reflog
    -M                    move/rename a branch, even if target exists
    --list                list branch names
    -l, --create-reflog   create the branch's reflog
    --edit-description    edit the description for the branch
    -f, --force           force creation (when already exists)
    --no-merged <commit>  print only not merged branches
    --merged <commit>     print only merged branches

root@kali:~/git/testing# 

И вот, наконец... я решил досмотреть ролик и на 9:40 секунде автор играючи все решил:

In []:

root@kali:~/git/testing# git push -f
Username for 'https://github.com': apython
Password for 'https://apython@github.com': 
Counting objects: 15, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (13/13), 14.87 KiB, done.
Total 13 (delta 3), reused 0 (delta 0)
To https://github.com/apython/forblog.git
 + bb135e8...a1de9d6 master -> master (forced update)
root@kali:~/git/testing# 

Но файл readme из GitHub на сервере исчез... Так что, это не лучший вариант... Но у того же автора, оказывается не два а несколько видео на эту тему. Есть целых два на тему конфликтов (4 и 5), а до этого - как создать нового юзера... Словом, вот это надо будет смотерть и дальше Jason Semko

Посты чуть ниже также могут вас заинтересовать