Библиотека сайта rus-linux.net
Знакомство с Git и Github для пользователей Linux
Оригинал: Beginning Git and Github for Linux UsersАвтор: Carla Schroder
Дата публикации: 20 November 2014
Перевод: Н.Ромоданов
Дата перевода: декабрь 2014 г.
Распределенная система контроля версий Git является приятным следующим шагом после Subversion, CVS, Mercurial и всего другого, что мы уже попробовали и с чем работали. Она отлично подходит для распределенной разработки, когда у вас есть несколько помощников, работающих над одним проектом, и для безопасной проверки всех видов сумасшедших изменений. На практике мы собираемся использовать бесплатный аккаунтом GitHub с тем, чтобы сдвинуться в правильном направлении и начать что-то делать.
Рис.1: Github является отличным местом для изучения Git.
Концептуально Git отличается от других систем контроля версий. Старые системы контроля версий отслеживают изменения в файлах, что вы можете обнаружить, если покопаетесь в конфигурационных файлах таких систем. Подход Git больше похож на моментальные снимки файловой системы, когда каждое изменение (commit) или сохраненное состояние является полный снипке системы, а не файлом, в котором запомнены различия. Git эффективно использует дисковое пространство, т. к. в каждом снимке сохраняются только изменения и ссылки на неизмененные файлы. Все изменения сопровождаются контрольными суммами, так что вы можете быть уверены в целостности данных и всегда сможете отменить изменения.
Git работает быстро, поскольку ваша работа полностью делается на вашем локальном компьютере, а затем помещается в удаленное хранилище. Все, что делается, делается для вас абсолютно безопасно, поскольку ничего не влияет на удаленный репозитарий до тех пор, пока вы в него не поместите изменения. И даже после этого у вас есть еще одно средство, обеспечивающее отказоустойчивость: ветки (branches). Система веток в Git является изумительным решением. Создайте ветку из ветки master, выполните любые самые ужасные эксперименты, а затем уничтожьте эту ветку или поместите результат в основную ветвь. Либо, если над основной ветвью работает еще кто-нибудь, вы можете сделать запрос на просмотр, а затем после того, как просмотр будет завершен, может слить результат в ветвь master.
А что, если после всех этих предосторожностей главная ветвь будет разрушена? Не беспокойтесь, потому что вы можете отменить ваше слияние.
Практика на Github
Самый быстрый способ немного попрактиковаться в использовании Git — это открыть бесплатный аккаунт на GitHub. На рис.1 показан мой тестовый аккаунт GitHub, который называется playground. Новые аккаунты Github предоставляются с заранее приготовленным репозитарием, в котором есть файл README, лицензия, а также кнопки для быстрого создания отчётов об ошибках, запросов, описаний Wiki, а также другие полезные функции.
На бесплатных аккаунтах GitHub разрешает создавать только общедоступные репозитории. В них любой может просматривать и загружать ваши файлы. Однако никто не может делать изменения или коммиттить данные, если у посетителя нет учетной записи GitHub и вы утвердили его как участника проекта. Если вам нужен личный репозиторий, который будет скрыт от всех, то вам потребуется платный аккаунт. За семь долларов в месяц вы получите пять личных репозиториев и неограниченное количество общедоступных репозитариев с неограниченным количеством участников.
Github любезно предоставляет возможность скопировать адреса URL с тем, чтобы можно было клонировать репозитории. Т.е. вы можете создать на вашем компьютере каталог для вашего репозитория, а затем клонировать репозиторий в этот каталог:
$ mkdir git-repos $ cd git-repos $ git clone https://github.com/AlracWebmaven/playground.git Cloning into 'playground'... remote: Counting objects: 4, done. remote: Compressing objects: 100% (4/4), done. remote: Total 4 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (4/4), done. Checking connectivity... done. $ ls playground/ LICENSE README.md
Все файлы будут скопированы на компьютер, и вы сможете их читать, редактировать и удалять точно также, как и любые другие файлы. Давайте улучшим файл README.md и изучим все великолепные возможностей использование ветвей в Git.
Использование ветвей
Механизм ветвления в Git отлично подходит для безопасного создания и тестирования изменений. Вы можете создавать и уничтожать в них все, что вы хотите. Давайте создадим одну из ветвей для редактирования файла README.md:
$ cd playground $ git checkout -b test Switched to a new branch 'test'
Для того, чтобы увидеть, где вы находитесь, запустите команду git status:
$ git status On branch test nothing to commit, working directory clean
Какие у вас созданы ветви?
$ git branch * test master
Звездочка указывает, на какой ветви вы находитесь. Ветвь master является вашей основной ветвью, т. е. той, в которой вы никогда не будете делать каких-либо изменений до тех пор, пока они не будут опробованы в некоторой другой ветви. Теперь внесем несколько изменений в файл README.md, а затем снова проверим статус:
$ git status
On branch test
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")
Разве это не приятно, что Git сообщает вам о том, что происходит, и дает советы. Чтобы отменить изменения, выполните следующую команду
$ git checkout README.md
Или вы можете удалить всю ветвь:
$ git checkout master $ git branch -D test
Либо вы можете сказать Git, что нужно отслеживать состояние файла:
$ git add README.md
$ git status
On branch test
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: README.md
На этом этапе Git отслеживает состояние файла README.md и это происходит во всех ветвях вашего проекта. Git предоставляет вам полезную возможность - если вы передумали и не хотите, чтобы Git отслеживал этот файл, то выполните команду git reset HEAD README.md. Это, а также все действия Git, запоминаются в каталоге .git в вашем репозитарии. Все хранится в простых текстовых файлах: файлы, контрольные суммы, а также то, что каждый пользователь что делал в удаленном или локальном репозитории.
Что делать, если вам нужно добавить несколько файлов? Вы можете указывать файлы по одному, например, git add file1 file2 file2, либо добавить все файлы с помощью команды git add *.
Когда есть удаленные файлы, вы можете использовать команду git rm filename, которая уберет их из Git, но не удалит их из вашей системы. Если у вас много удаленных файлов, то воспользуйтесь командой git add -u.
Коммитим файлы
Теперь давайте закоммитим (внесем в наш проект) наш измененный файл. Он будет добавлен в нашу ветвь и он больше не будет присутствовать в других ветвях:
$ git commit README.md [test 5badf67] changes to readme 1 file changed, 1 insertion(+)
Вам будет предложено добавить сообщение, относящееся к данному коммиту. Хорошим тоном считается писать ваши сообщения подробно и по-существу, но сейчас мы не будет слишком привередливы. Теперь ваш отредактированный файл был закомммитчен в ветви test. Он не был объединен с ветвью master и не был помещен в основную ветвь; он просто помещен в проект. Если вам нужно сделать что-то еще, то подходящий момент для того, чтобы остановиться.
А что, если нужно закоммитить несколько файлов? Вы можете закоммитить определенные файлы или все имеющиеся файлы:
$ git commit file1 file2 $ git commit -a
Как вы узнаете, какие замоммитченные файлы еще не были перемещены в основную ветвь и до сих пор находятся в ветвях? Команда git status об этом вам не сообщит, поэтому используйте следующую команду:
$ git log --branches --not --remotes
commit 5badf677c55d0c53ca13d9753344a2a71de03199
Author: Carla Schroder
Date: Thu Nov 20 10:19:38 2014 -0800
changes to readme
В этом списке указаны все коммиты, не слитые с основной ветвью, и когда в нем ничего нет, то это значит, что все коммиты были перенесены в основную ветвь. Теперь давайте перенесем этот коммит в основную ветвь:
$ git push origin test Counting objects: 7, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 324 bytes | 0 bytes/s, done. Total 3 (delta 1), reused 0 (delta 0) To https://github.com/AlracWebmaven/playground.git * [new branch] test -> test
Для входа GitHub, возможно, будет предложено ввести ваши учетные данные. Git запоминает их в кэше на 15 минут, но вы можете изменить эту настройку. В приводимом ниже примере кэширование устанавливается на два часа:
$ git config --global credential.helper 'cache --timeout=7200'
Теперь перейдите в Github и посмотрите на вашу новую ветвь. Github выдает список всех ваших ветвей и вы можете просматривать файлы в различных ветвях (рис.2).
Рис.2: Ваш новый коммит и ветвь в Github
Теперь вы можете создать запрос на добавление изменений в основную ветвь, нажав для этого на кнопку Compare & Pull Request. У вас будет еще один шанс просмотреть свои изменения перед их слиянием с веткой master. Вы также можете создать такой запрос из командной строки компьютера, но это довольно трудоемкий процесс, и, к тому же в сети вы можете найти много инструментальных средств, которые облегчат этот процесс. Поэтому на данный момент, мы будем пользоваться замечательными кнопками GitHub.
Github позволяет вам просматривать файлы в формате обычного текста и поддерживает использование большого количества языков разметки, так что у вас есть возможность просматривать другие сгенерированные варианты просмотра файлов. В этот момент вы можете добавить в ветвь сразу много изменений. Вы также можете вносить изменения непосредственно на Github, но когда вы так поступаете, у вас возникнут конфликты между версией, находящейся в интернете, и локальной версией. Когда в ваших изменениях все вас будет устраивать, нажмите кнопку запроса слияние Merge. Вы должны нажать кнопку дважды. Для того, чтобы увидеть может ли слияние быть выполнено чисто, Github автоматически проверит ваш запрос на слияние, и если у вас возникнут конфликты, вам придется их исправить.
Еще одна приятная особенность Github состоит в том, когда у вас есть несколько ветвей, вы можете выбрать, какую из них использовать при слиянии; для этого нажмите кнопку Edit, расположенную справа от списка ветвей (рис.3).
Рис.3: Выбираем, какую ветвь использовать при слиянии
После того, как слияние будет выполнено, нажмите для поддержания общего порядка кнопку удаления ветви Delete Branch. После этого на вашем локальном компьютере сначала слейте ветвь с ветвью master, а затем вы можете удалить эту ветвь без всяких нареканий со стороны Git:
$ git checkout master $ git pull origin master $ git branch -d test
Вы можете принудительно удалить ветку, указав заглавную букву -D:
$ git branch -D test
Отмена изменений
Опять же, проще всего использовать кнопки Github. Вам будет показан список всех изменений, и вы можете отменить любое из них, нажав на соответствующую кнопку. Вы даже можете восстановить удаленные филиалы.
Все эти действия вы также можете выполнить исключительно из командной строки, что будет интересной темой для следующей статьи, т. к. все будет гораздо сложнее. В качестве исчерпывающего руководства по Git используйте бесплатную книгу Git.