Видео ролики бесплатно онлайн

Смотреть мамки видео

Официальный сайт panajotov 24/7/365

Смотреть видео бесплатно

23.06.2009 04:23

lwilisGit - что нужно для начала?

Немного расскажу про систему контроля версий git. Базой этой заметки служат обе части gittutorial, man gitignore, man git-update-index, man git-reset. Заметка подойдет для быстрого старта. Пригодится для контроля изменений в /etc.



Система контроля версий полезна для документирования изменений в конфигурации вашей ОС. Во-первых, появляется возможность проводить эксперименты при конфиругировании, имея возможность вернуться к заведомо рабочим параметрам. Во-вторых, проще клонировать действительно нужные параметры, если завести несколько веток в репозитарии, - две (основная и экспериментальная) для PC и две для нетбука.



Ветка (branch) - это одна из версий состояния файлов в каталоге вашего проекта

Документирование строится путем осуществления commit`ов в ветку.



Commit - это способ регистрации изменения в одном или нескольких файлах проекта. Здесь нужно заметить, что после внесения изменений в файл или создания нового файла, необходимо добавить файл в репозитарий. И после добавления можно создать commit, то есть зафиксировать изменение и дать ему описание.



Внутри репозитарий git представляет из себя каталог .git, расположенный в каталоге проекта. В .git лежат как служебные файлы, так и наши рабочие данные. Рабочие данные находятся в каталоге .git/objects. Углубляться в устройство git здесь не буду, но в конце заметки будет ссылка именно по внутренностям git.



Для начала рекомендую потренироваться "на кошках", поэтому сразу в /etc не полезем.

Поехали.

 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
$ mkdir ~/test && cd ~/test

$ git config --global user.name "Имя владельца репозитария" #Будем лицезреть заковыченные строки

$ git config --global user.email "[email protected]" #в поле Author commit`ов

$ git init

Initialized empty Git repository in .git/

$ touch workfile autochangingfile #создадим пару файлов для добавления в проект

$ git add . #добавили все файлы каталога в репозитарий

$ git commit -m "initial commit" #сделали первый commit в репозитарий

Created initial commit 5ea37d2: initial commit

0 files changed, 0 insertions(+), 0 deletions(-)

create mode 100644 autochangingfile

create mode 100644 workfile

$ git branch current #создали ветку current

$ git checkout current #перешли на ветку current

Switched to branch "current"

Начало положено. Дальнейшая работа предполагает внесение изменений в файлы и выполнение операций добавления, с последующим выполнением commit`ов.


Но, сразу после начала знакомства с git мне потребовалось смотреть на прогресс и состояние репозитарияотменить слежение за изменениями в некоторых файлахнекоторые файлы я не хотел добавлять в репозитарий, и хотел, чтобы git их игнорировалмне нужно было откатывать свои изменения


Продолжим.

 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
$ git branch      #Убедимся, что находимся экспериментальной ветке

* current

master

$ git status #Убедимся, что проект готов к изменениям, то есть git не выдает предупреждений, и рабочий каталог чист (все изменения внесены в commit)

# On branch current

nothing to commit (working directory clean)

$ cat>workfile

some changes

^C

$ git status #Обращаем внимание на предупреждение git о изменениях в файле. Так как файл был ранее внесен в репозитарий, то можно делать сразу commit с опцией -a

# On branch current

# Changed but not updated:

# (use "git add <file>..." to update what will be committed)

#

# modified: workfile

#

no changes added to commit (use "git add" and/or "git commit -a")

$ git commit -a -m "new test feature"

Created commit 253a417: new test feature

1 files changed, 1 insertions(+), 0 deletions(-)

$ git log #Таким образом можно пронаблюдать изменения в проекте

commit 253a41769ba84ddba5e5aee020f4177a6e09a34c

Author: Alex Polyakhov <[email protected]>

Date: Tue Jun 23 03:47:37 2009 +0400



new test feature



commit 5ea37d28f96e465fb534db7bb88acdb7150fb670

Author: Alex Polyakhov <[email protected]>

Date: Tue Jun 23 03:37:11 2009 +0400



initial commit

lines 1-11/11 (END)

Предположим, что изменения в файл autochangingfile вносятся каким-то системным процессом, и нас устраивает ничего о них не знать, тем не менее файл в проекте требуется.

 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
$ cat>autochangingfile

some auto added entry

^C

$ git status

# On branch current

# Changed but not updated:

# (use "git add <file>..." to update what will be committed)

#

# modified: autochangingfile

#

no changes added to commit (use "git add" and/or "git commit -a")

$ git update-index --assume-unchanged autochangingfile #Сказали git, что за файлом autochangingfile наблюдать не нужно

$ git status

# On branch current

nothing to commit (working directory clean) #А git - не против

$ touch tempfile

$ cat>>.git/info/exclude #Файл tempfile - суть временный, и его не нужно ни отслеживать, ни вообще помещать в проект. Вносим его в список игнорируемых.

tempfile

^C

$ git status

# On branch current

nothing to commit (working directory clean) #А git - не против

$ cat>workfile #ВПЕЗАПНО испортили рабочий файл

weird change

^C

$ git commit -a -m "mega cool feature" #Еще и commit сделали

На текущем этапе есть два варианта. В первом случае сделаны неверные изменения в самом файле, а во втором - изменения в файле необходимы, но вот коммит сделан неверно (например текст сообщения). Первый случай - тяжелый, второй - мягкий. Соответственно для отмены и того, и другого нужна команда reset, но в первом случае с параметром --hard, во втором --soft. Я рассморю первый случай.

 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
$ git log

commit 60c6d91f35fc72b5643141c0e194374f8ae05dd2 #Изменения этого коммита нам не нужны

Author: Alex Polyakhov <[email protected]>

Date: Tue Jun 23 04:10:59 2009 +0400



mega cool feature



commit 532c0f612a8b11a50b6d24259367af25430bbe80 #Есть желание откатиться на этот коммит

Author: Alex Polyakhov <[email protected]>

Date: Tue Jun 23 03:57:48 2009 +0400



new feature



commit 5ea37d28f96e465fb534db7bb88acdb7150fb670

Author: Alex Polyakhov <[email protected]>

Date: Tue Jun 23 03:37:11 2009 +0400



initial commit

$ git reset --hard 532c0f #Полностью имя коммита можно не набирать, это было бы негуманно

HEAD is now at 532c0f6 new feature

После операции reset можно убедиться в успешном откате командами git status и git log

На этом, пожалуй, закончу. Если будет интересно, то тему слияния веток, сравнение состояния файлов в разных ветках и что-нибудь еще рассмотрю в следующий раз.

внутренности git


Тэги: git vcs новичку
+ 12 -
Похожие Поделиться

exelens 23.06.2009 07:50 #
+ 0 -
Я бы начал с пояснения, кому оно нужно а не для чего.
Мне например оно не нужно.

А чем новичёк отличается от меня?
lwilis 23.06.2009 10:12 #
+ 1 -
трудно сказать. Большие дядьки используют для контроля кода ядра, а мне пригодилась для наведения порядка в /etc - масштабы, прямо скажем, диаметрально противоположные.
И да, я полагаю, что от новичка я тоже не сильно отличаюсь.
А заметку делал для тех, кто уже что-то слышал и хочет попробовать, но "не подступиться"
rakoth 23.06.2009 10:21 #
+ 1 -
Тоже не так давно взялся за гит.
Может, стоит осветить такое:
1)Застрял по началу на вопросе: http или ssh? Выбрал оба. =)
2)Клиенты. Для виндузей-то нашёл черепашку, как и для свинки, под макось - gitx
lwilis 23.06.2009 10:25 #
+ 0 -
да, я помню ты в жуйке отписывался на эту тему ;)
Пока что не обещаю ответов на эти вопросы
rakoth 23.06.2009 10:25 #
+ 1 -
//случайно отправил. Удалить/редактировать нельзя?
А для себя что-то ничего подобного eSvn найти не могу. Консоль решает!
3)веб-морды для управления. Как по мне, так и gitosis отличное средство, но вот для других...
umka_ssw 23.06.2009 10:37 #
+ 0 -
Сам пользуюсь SVN, посматриваю на git, готовлюсь :)
Статья как раз в тему, типовые случаи описаны. За это спасибо.
Увидел интересное отличие: в SVN коммит подразумевает, что надо забрать все изменённые файлы, а в GIT, как я понял, надо явно помечать, что войдёт в коммит или писать опцию -a. Тут при переходе предвижу наступание на грабли несколько раз, пока новые рефлекс не выработается :)
lwilis 23.06.2009 10:59 #
+ 0 -
Рад, что заметка в тему.
Пока разбирался с git, натыкался на статьи в стиле "как переехать с svn на git", но пропускал их, чтоб голову не морочить. Ну не пользовался я раньше VCS.
Тем не менее главное отличие от svn в том, что git - распределенная (DVCS). Поэтому работать можно не подключаясь "главному" репозитрарию (в кавычках, потому что как такового главного нет, все репы равноценны, просто можно договориться, какой реп считать главным), а следовательно "забирание" нужно делать перед коммитом в "главный". То есть сначала кодим и коммитим у себя, потом забираем из главного репа, разруливаем конфликты, коммитим в главный.
rakoth 23.06.2009 11:13 #
+ 1 -
А по-моему более важное отличие - поддержка бранчей и аккуратный merge.
И такая штука, как отложенные коммиты тже полезно для нескольких разработчиков.
В свинке такого очень не хватает. А привыкать придётся долго.
Короче, есть резон посмотреть на git после свинки. Но переносить проекты с свн на гит особого резона нет.
umka_ssw 23.06.2009 11:19 #
+ 0 -
По мне так главный плюс гиты -- это как раз его локальность, помимо прочего конечно. Часто возникали задачи, когда хотелось локальную версионность без лишних заморочек с поднятием репозитария, его ведением и т.п. Гита как раз для этого очень подходит.
lwilis 23.06.2009 11:32 #
+ 0 -
я о том же.
bobry 23.06.2009 15:09 #
+ 1 -
как впрочем и bzr и hg (:
xT 23.06.2009 11:19 #
+ 0 -
Увидел интересное отличие: в SVN коммит подразумевает, что надо забрать все изменённые файлы...

По умолчанию - всё. По желанию - нужное
ukko 23.06.2009 11:16 #
+ 1 -
Отличная статья!

Как раз в тему для тех кто знает и любит консоль, другие системы контроля версий (svn, cvs) и подумывает переходить на git.

Тут наверное одни из самых типичных случаев преведены, мне очень понравилось это руководство, спасибо :)
lwilis 23.06.2009 11:35 #
+ 1 -
спасибо за отзыв
Kane 23.06.2009 11:22 #
+ 4 -
Спасибо, познавательно.
А можешь сказать пару слов о git в сравнении с hg?
lwilis 23.06.2009 11:34 #
+ 0 -
До git я не пользовался VCS.
bobry 23.06.2009 15:08 #
+ 1 -
а объективные причины выбора git, а не hg имеют место быть?
или все получилось спонтанно?
lwilis 23.06.2009 15:22 #
+ 0 -
Не то чтоб спонтанно, просто решил попробовать git или Mercurial, начал с git - он мне так понравился, что mercurial я даже смотреть не стал.
А про существование hg я узнал уже после чтения манов git`а.
lwilis 23.06.2009 15:41 #
+ 2 -
такс, сходил по ссылке.
Оказывается hg и mercurial - синонимы :)
bobry 23.06.2009 15:43 #
+ 2 -
^^ весело
SMiX 23.06.2009 14:49 #
+ 1 -
Мои впечатления: hg интуитивно понятней, намного удобней настройка(как веб-обёртка репа, так и сам реп и личный конфиг юзера/хотя с последними двумя - спорно/)
В hg присутствует какая-то абстрактная нумерация коммитов

Много раз пытался перелезть на гит - не вышло. С hg как-то работать приятней.
Бытует мнение, что, в отличие от других DVCS, гит переполнен фичами. Но тот же mercurial поддерживает расширения(ибо питон )), которые реализуют самые нужные вещи, отсутствующие в ядре, и реализуют с учётом опыта их использования в гите. Некоторые включаются в базовую поставку системы.

Git позволяет редактировать любой элемент дерева коммитов, mercurial разрешает отменить лишь последний коммит. Хотя здесь я не уверен, что всё именно так, как кажется.
bobry 23.06.2009 15:07 #
+ 1 -
несмотря на небольшой опыт - уже несколько раз столкнулся с невозможностью hg слить больше двух веток за раз. вроде бы не очень существенно, но не айс.
SMiX 23.06.2009 15:26 #
+ 1 -
Вот хорошая ссылка. Даже не знаю, что делает hg ярче гита - сама статья или комментарии )
http://alexlebedev.com/blog/mercurial-flying-fine/
bobry 23.06.2009 15:31 #
+ 1 -
скриншот актуальный) я такое тоже уже видел
гит подобные штуки не вытворяет?
SMiX 23.06.2009 15:38 #
+ 0 -
Конечно вытворяет. Там же ниже написано, что это просто результат ошибки участника проекта, который с непривычки при коммите промахнулся с бранчем. Другое дло, что в гите ка-кто реализована правка истории. Хотя сомневаюсь, что можно менять саму структуру дерева.

Перевод с translated.by:
Git предоставляет большой список команд, число которых в версии 1.5.0 достигает 139 уникальных единиц. Он имеет репутацию инструмента, сложного для изучения. В сравнении с Git, Mercurial делает упор на простоту.

Что касается производительности — Git очень быстр. В некоторых случаях он быстрее, чем Mercurial (по крайней мере под Linux), а в других быстрее оказывается Mercurial. Однако под Windows как производительность, так и общий уровень поддержки, во время написания этой книги у Git гораздо хуже, чем у Mercurial.

В то время как репозиторий Mercurial не требует операций по техническому обслуживанию, репозиторий Git требует частых ручных "перепаковок" собственных метаданных. Если этого не делать, производительность начинает падать, наряду с увеличением объёма занимаемого дискового пространства. Дисковый массив сервера, содержащего несколько Git репозиториев, по отношению к которым не выполняется строгое правило частой "перепаковки", рано или поздно забивается под завязку, в результате чего процесс ежедневного резервного копирования легко может занимать более 24 часов. Только что "запакованный" репозиторий Git занимает немного меньше места, чем репозиторий Mercurial, но объём не перепакованного репозитория будет на несколько порядков больше.

Ядро Git написано на языке С. Многие команды Git реализованы в виде Shell скриптов или скриптов на языке Perl и уровень качества данных скриптов сильно разнится. Я встречал несколько установок, в которых скрипты тупо продолжали выполнение, несмотря на наличие фатальных ошибок.

Mercurial предоставляет возможность импорта истории версий из репозитория Git.
lwilis 23.06.2009 15:46 #
+ 0 -
есть rebase - эта команда позволяет полностью переделать ветку, вынести несколько коммитов в другую ветку. Подробности пока что сам не знаю
SMiX 23.06.2009 15:41 #
+ 1 -
Основной довод в пользу git - можно работать с ветками в одной директории, в то время как в Mercurial и остальных системах это делается в клонированных репозиториях
bobry 23.06.2009 15:44 #
+ 1 -
по моему для hg был плагин реализующий такую возможность
или я что то путаю?
SMiX 23.06.2009 16:52 #
+ 1 -
В hg есть плагин, реализующий аналог git stash
SMiX 23.06.2009 19:44 #
+ 2 -
http://www.selenic.com/mercurial/wiki/MqExtension
Вот нашёл. Наиприятнейшая штука :)
bobry 23.06.2009 15:10 #
+ 1 -
оффтоп: по моему подстветка синтаксиса как то лажает, нет? я кроме циферок слева - никакой "подстветки" не вижу

оффтоп x2: она *подсветка* тоже самописная?
bobry 23.06.2009 15:14 #
+ 1 -
что нибудь такое не хотите?
http://alexgorbatchev.com/wiki/SyntaxHighlighter
lwilis 23.06.2009 15:26 #
+ 1 -
с подсветкой мой косяк. Поправил :)
bobry 23.06.2009 15:29 #
+ 1 -
все равно куцо как то выглядит (:
хотя это наверное уже не проблема хайлайтера
booley 23.06.2009 18:19 #
+ 0 -
Подсветка не самописная. Название на Г начинается. Что-то вроде ~ Geshi
bobry 23.06.2009 15:28 #
+ 2 -
кстати если кому интересно - могу написать аналогичную статью про hg (:
lwilis 23.06.2009 15:33 #
+ 0 -
Пиши, конечно. Я бы с удовольствием почитал

В хорошем качестве hd видео

Онлайн видео бесплатно


Смотреть русское с разговорами видео

Online video HD

Видео скачать на телефон

Русские фильмы бесплатно

Full HD video online

Смотреть видео онлайн

Смотреть HD видео бесплатно

School смотреть онлайн