Шуточная обложка книги, которая так подходит следующему тексту:
Для представления того, как работает система контроля версий git, была придумана следующая сказочная концепция, она не описывает подготовительные операции, которые выполняются обычно один раз (они описаны с соответсвующем файле в этой же папке (git_install_and_setup.md):
Представьте, что в 4000 году все люди переселятся на другую планету, Дед Мороз тоже решил переселиться.
Для этого он собрал своих помощников, в том числе и вас, заместителя Деда Мороза и управляющего его базой, да инструменты, которые он скромно назвал "grand incredible tools" (далее просто git). (Этот Дед Мороз любит называть вещи на заморский манер.)
Инструментов-то много пришлось сложить в сани, поэтому Дед Мороз все-таки решил назвать свои сани, и назвал он их "GitHub"(github.com).
Вы решили предварительно создать образ базы, и положить его в сани "GitHub", чтобы быстро воссоздать на новом месте:
На сайте github.org после входа в аккаунт в черной строке сверху увидите справа +, нажимаете на него, а в появившемся меню на "New repository".
Вы подписываете этот образ и даете ему краткое описание, причем понимаете, что с этим образом будут работать другие, а скрыть от любопытных все равно не получится , так что жизненно необходимо положить документацию:
В соответствующих полях пишите название репозитория (например, digital_literary_studies) и краткое описание, убеждаетесь, что выбрано Public (за Private просят деньги), а далее
ОБЯЗАТЕЛЬНО ставите галочку у "Initialize this repository with a README", что создаст файл README.md, это и есть визитная карточка репозитория, начальная точка в его изучении. После всего этого жмете на "Create repository".
Прилетев на планету, вы ищите, где в санях лежит ваш образ, и указываете инструментам его местоположение да место, где хотите разместить базу, так на новом месте возводите базу:
На странице репозитория в GitHub сверху справа есть зеленая кнопка "Clone or download" - после нажатия открывается меню, где указан адрес: можете скопировать его вручную или нажать на кнопку с планшетом и стрелочкой в той же строке, что сделает то же самое.
Затем находите терминал (Mac OS, Linux) или cmd (Windows) через поиск и в нем пишите: В терминале/cmd переходите в директорию, где хотите разместить проект (в стандартно настроенной любой системе(Windows/MacOs/Linux) cd Desktop отправит в папку с содержимым рабочего стола; C помощью cd можно перемещаться в папку, если эта папка существует, иначе ее надо создать вначале либо как обычно это делаете, либо в консоли командой mkdir *название папки*), и вводите git clone *а тут ссылку, которую скопировали* (парные звездочки здесь и далее при подстановке значения следует убрать)
База готова, в нее можно заселиться:
cd *тут название, которое вы выбрали при создании репоозитория*
Очередной Новый Год близко, поэтому начинается работа, по созданию подарков к празднику:
Добавление/изменение/удаление файла в папке репозитория контроллируются системой контроля версий
После того, как насобрали желаемое подарков, надо сказать, чтобы Дед Мороз обратил на него внимание, и не забыл взять с собой:
git add *путь к файлу* - сообщает git, что вы хотите записать в репозиторий именно этот файл
git add *путь к директории* - сообщает git, что вы хотите записать в репозиторий изменения всего содержимого директории в том числе и вложенных директорий.
git add -A - сообщает git, что вы хотите записать в репозиторий все изменения проекта
git add * - сообщает git, что вы хотите записать в репозиторий все изменения проекта КРОМЕ действий по удалению файлов
Можно сказать сложить Деду Морозу, что он может упаковать подарки, на которые ОБРАЩАЛИ его внимание, в мешок. Этот мешок обязательно надо подписать, чтобы знать, в каком из однообразных красных мешков лежит каждый подарок:
git commit -m "*некоторая информативная подпись*"
Если после команды вывело "nothing to commit", то это значит, что вы не добавили ни одного файла с помощью git add (например, вы сделали git add на неизмененный файл или вовсе не писали git add после прошлого git commit, хотя надо делать add после каждого commit)
Если написать просто git commit, то получите наказание в виде тектосового редактора vim. Вам откроется пустой файл или файл, где строки начинаются с #, в который (после всех #, если они есть) вы должны написать *некоторую информативную подпись*. Нажатие на i (язык раскаладки клавиатуры имеет значение) переводит в режим редактирования (внизу появилось --INSERT--), теперь вы можете написать подпись, когда закончили писать, нажимайте клавишу Esc [полное название - Escape] (--INSERT-- пропадет), теперь надо написать :wq (w - write, q - quit, эти три символа должны отобращзиться там же, где было --INSERT--) и нажать Enter. Поздравляю, вы выбрались из тюрьмы! (:w - сохраняет файл, но не выходит из редактора; :q - выходит из файла, если он не изменился с последнего сохранения; :q! - отменить изменения после последнего сохранения; http://vim.wikia.com/wiki/Undo_and_Redo )
Новый Год! Пора мешки с подарками относить в сани "GitHub":
git push - предложит ввести логин и пароль от GitHub, если введено все верно, то ваши файлы будут показываться в вашем репозитории на сайте github.com
Дед Мороз должен раздать за ночь всем подарки, возвращаться на базу он не будет, чтобы что-то изменить в подарках в случае проблемы:
На том уровне git-а, который "не взорвет человеку мозг" окончательно, не получится удалить из истории файл с какими-нибудь конфиденциальными данными, даже если Вы удалите файл из репозитория или затрете текст - в истории все равно все останется, так что будьте осторожны.
У саней есть магическая способность самим создавать подарок, но по нескольким причинам использование этой возможности порицается коллегами по цеху Деда Мороза, например, на каждый подарок нужен свой красный мешок, что неудобно и затратно:
github.com предоставляет возможность менять файлы в репозиториях, есть у вас есть разрешение на изменение репозитория, то в правой части экрана прямо над содержимым файлом можно увидеть карандаш и мусорное ведро (изменить и удалить соответственно). Но если вы скажете, что так делаете, знакомому программисту, то он Вас будет громко или тайно, но порицать, потому что "это не по феншую", и потому что каждое изменение файла/изменение нескольких файлов делает по одной записи в историю за одно изменение/один файл.
Стоит упомянуть, что Дед Мороз иногда хочет порадовать Снегурочку подарком, но выбирать самому у него не получается, поэтому этим занимается его заместитель, то есть Вы, так что Вы сообщаете ему какой подарок нужно привезти на санях на базу:
На странице репозитория возле зеленой кнопки "Clone and download" есть кнопка "Create new file" (папки создать через сайт на данный момент невозможно); по тем же причинам, что и в случае с изменением/удалением файла на сайте, в профессиональном сообществе считается порицательным.
Вы - управленец не промах, поэтому Вам важно, чтобы была правильная отчетность, так что иногда собираете информацию и о тех подарках, которые сделаны вне базы:
Команда git pull позволяет получить изменения в репозитории, которые сделаны не с используемого компьютера. Например, если изменения произошли с сайта или с другого компьютера.
От одного заместителя другому передается легенда о древнем заместителе, который пренебрегал отчетностью: привез Дед Мороз подарок Снегурочке, и оставил его в санях, как имеет обыкновение делать, чтобы под руководством заместителя его подготовили. Заместителю лень было идти смотреть, что в санях, и он решил вручить собственноручно сделанный подарок, который был, на самом деле, гораздо лучше. Дед Мороз узнает об этом раньше, он-то чует ауры подарков, поэтому приходит выяснять отношения. Получается конфликт, Дед Мороз хочет подарить свой подарок, но с ним никак не поспоришь, а свой труд заместителю жалко. Тут возникает перед заместителем дилемма: сделать, как Дедушка велит, или спрятать подарок вне базы и потом подменить подарок:
Разберем случай, который вероятнее всего может встретиться начинающему в системах контроля версий и GitHub, в частности: Вы делаете изменение на сайте файла a.txt, соответственно, делаете commit в удаленный репозиторий, но потом решаете изменить a.txt, который лежит в локальной папке проекта, причем, могло так получится, что изменили как минимум одну строку, которую изменяли на сайте, не сделав предварительно git pull, потом пытаетесь либо сделать git pull, либо отправить новый a.txt на github.org, как делали это обычно:
В таком случае вы можете увидеть три вида ошибки (текст может быть не в точности таким, но похожим):
1) error: Entry '<fileName>' not uptodate. Cannot merge. (Это будет выведено, если git add не действовал на a.txt)
2) error: Entry '<fileName>' would be overwritten by merge. Cannot merge. (git add действовал на a.txt, но Вы не сделали git commit [-m "..."])
3) CONFLICT (content): Merge conflict in <fileName> Automatic merge failed; fix conflicts and then commit the result.
Здесь понятно расписано о разрешении конфликтов: http://genomewiki.ucsc.edu/index.php/Resolving_merge_conflicts_in_Git Единственное, что будет не очень понятно "staged changes"/"Changes in staging area" - и другое с производными "stage" означает состояние после команды git add ..., "unstage" - соответсвенно, до. Использование git stash похоже на "спрятать, а потом подменить", git checkout <file> - убрать все изменения в файле, которые сделаны после последнего коммита, git reset может отменить неотправленные коммиты в локальном репозитории, но с этой командой надо работать осторожно.
Надеюсь, эта полусказка добавила понимания работы с git.
С прошедшими праздниками, успехов в новом и последующих годах!