LINUX.ORG.RU

Управление исходным кодом с помощью Git

 ,


0

0

Git — программное обеспечение с открытым исходным кодом для управления версиями, разработанное Линусом Торвальдсом для использования в управлении разработкой ядра Linux®. Его можно скачать и использовать для работы с ядром — или для собственных программных проектов. В этой статье показывается, как начать разработку в среде Linux с помощью инструментария Git.

>>> Подробности

★★★

Проверено: Shaman007 ()
Ответ на: комментарий от prizident

несвежая статья, как обычно у IBM. Теперь команды через черточку deprecated.

Voker57 ★★
()

> git-1.4.0

как раз вовремя перевели

Voker57 ★★
()

> Создание файлов различий (diff) Наконец, может потребоваться создать текстовый файл, содержащий только отличия между измененным кодом и первоначальным. Это файл обычно создается с помощью утилиты diff и называется diff.

Мда. Впрочем, может во времена git 1.4.0 команды git diff еще не было?

Voker57 ★★
()

Git штука хорошая и самая быстрая, удобная. Однако, статья видимо старая - о нем не упоминается, я предпочитаю Mercurial - 1) практически идентичный git-у командный интерфейс 2) поддержка в NetBeans + хороший плагин к eclipse 3) удобные виндовые клиенты (а что, виндузятники они как дети малые, им надо чтобы все через окошечки, только так удобно) - если работаете над кроссплатформенным проектом и коллеги пользуются оффтопиком 4) настраивается из консоли просто, быстро, элементарно 5) проще отсылать коммиты - это делается быстро, просто, удобно (меня знакомый спец по git-у консультировать какие танцы он выполняет для отправки патча в основной репозиторий... это жесть - поправьте если ошибаюсь) 6) Mercurial под GNU GPL v2 (имеется ввиду что пользуйтесь на здоровье)

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

> 5) проще отсылать коммиты - это делается быстро, просто, удобно (меня знакомый спец по git-у консультировать какие танцы он выполняет для отправки патча в основной репозиторий... это жесть - поправьте если ошибаюсь)

git format-patch, git send-email, куда уж проще? А по ssh так и вообще нефиг делать.

> 6) Mercurial под GNU GPL v2 (имеется ввиду что пользуйтесь на здоровье)

как ни странно, git тоже под GPL.

Интерфейсов git сильно не хватает, да. Но эта ситуация исправляется.

Voker57 ★★
()
Ответ на: комментарий от I-Love-Microsoft

> Git штука хорошая и самая быстрая, удобная. Однако, статья видимо старая - о нем не упоминается, я предпочитаю Mercurial

Git для инопланетян, Mercurial - для людей.

tailgunner ★★★★★
()

"Git можно использовать для управления локальными хранилищами, не зеркалируя [!!! сейчас это лингвистическое открытие подсвечено Firefox'ом, на gramota.ru тоже такого слова нет - B.] работу кого-то другого. Например, если нужно использовать Git для управления своим собственным вкладом в открытый проект, можно начать, создав хранилище Git на основе копии проекта." (c) IBM EE/A

"You can use Git to manage local repositories without mirroring someone else's work." (c) в оригинале

"mirror (REPRESENT)

1 to represent something truthfully:

2 to be very similar to something:

(с) Cambridge Advanced Learner's Dictionary

Ну и "грамотны" же "переводчики" в IBM EE/A. "Подстрочник" доставляющий. Чисто "Новояз" ( "Newspeak" (с) G.Orwell )

------

Есть нормальная документация http://www.kernel.org/pub/software/scm/git/docs/user-manual.html и безграмотный пересказ от on-line переводчика не нужен.

Bioreactor ★★★★★
()

Почти четыре года бойану, а LOR только узнал...

raorn
()
Ответ на: комментарий от tailgunner

> Git для инопланетян, Mercurial - для людей.

Git для разработчиков ядра, Mercurial и SVN - для жабабыдлокодеров (типа меня).

Bioreactor ★★★★★
()
Ответ на: комментарий от Voker57

> Git для тех, кто может осилить интерфейс и workflow, не похожие на SVN/CVS.

Угу. Кто с трех раз угадает, как в гите удалить удаленный (в смысле remote) бранч? Хорошо, что инопланетян много и гугл их индексирует.

Ну не в жисть бы не догадался, что git push origin :branch_name

P.S. Гитоюзер, на меркуриал не хочу ибо с марсом уже переписываюсь.

baverman ★★★
()
Ответ на: комментарий от Bioreactor

>> Git для инопланетян, Mercurial - для людей.

> Git для разработчиков ядра

Изначальным Git даже разрабы ядра пользоваться не хотели :) Говорят, правда, за несколько лет его облагородили... но нафиг надо? PR не в счет.

tailgunner ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

> 3) удобные виндовые клиенты (а что, виндузятники они как дети малые, им надо чтобы все через окошечки, только так удобно)

А что, под Windows нет git gui (на Tk)?

> 4) настраивается из консоли просто, быстро, элементарно

git также просто настраивается. git config --help

> 5) проще отсылать коммиты - это делается быстро, просто, удобно (меня знакомый спец по git-у консультировать какие танцы он выполняет для отправки патча в основной репозиторий... это жесть - поправьте если ошибаюсь)

Зависит от апстрма. У нас на git.alt проблем с отправкой файлов нет.

Всё же Mercurial IMHO не так распространён как Git. У нас в ALT Linux вообще сборка пакетов сделана только через Git (http://www.altlinux.org/Git.alt/Краткое_руководство). Красота!

Skull ★★★★★
()
Ответ на: комментарий от Skull

> У нас в ALT Linux вообще сборка пакетов сделана только через Git

Вот тут бы и перечислить преимущества, но... нет перечисления :D

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Git для инопланетян, Mercurial - для людей.

Вы, конечно же, можете адекватно описать различия между этими продуктами? Или так, пришли лозунгом помахать?

Skull ★★★★★
()
Ответ на: комментарий от Voker57

> Git для тех, кто может осилить интерфейс и workflow, не похожие на SVN/CVS.

Для меня начать работать с Git оказалось гораздо проще, чем с CVS и SVN.

Skull ★★★★★
()
Ответ на: комментарий от tailgunner

Раз ядром пользовались, то и Git должны были использовать. Так сказать, "в нагрузку". :)

Для ядра, в принципе, нормально. "Прикладникам", действительно, не совсем подходит. Или, точнее, совсем не подходит. Хотя для Eclipse плагин есть http://repo.or.cz/w/egit.git.

Bioreactor ★★★★★
()
Ответ на: комментарий от Skull

>> Git для инопланетян, Mercurial - для людей.

> Вы, конечно же, можете адекватно описать различия между этими продуктами?

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

> Или так, пришли лозунгом помахать?

Симметрично.

tailgunner ★★★★★
()
Ответ на: комментарий от Bioreactor

> Раз ядром пользовались, то и Git должны были использовать. Так сказать, "в нагрузку". :)

Я не настолько серьезный пользователь ядра, чтобы осваивать такое поделие, как Git.

> Хотя для Eclipse плагин есть http://repo.or.cz/w/egit.git.

Это тот, где Git реализован на Яве? %)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Вот тут бы и перечислить преимущества, но... нет перечисления :D

Преимущества http://www.altlinux.org/Gear и http://www.altlinux.org/Git.alt/Введение прямо проистекают из достоинств Git:
- распределённая разработка
- транзакционный подход в управлении пакетами
- простота управления исходным кодом
- простота и удобство создания патчей
- интеграция в VCS апстрима, в том числе и по истории
- прозрачная сборка как локально, так и на сервере (в последнем случае нужно лишь создать подписанный тег и задать команду на сборку по ssh)
- быстрое бэкпортирование
- малый трафик при постановке на сборку в репозиторий
- разнообразные проверки собираемых пакетов

В общем, у нас теперь всё собирается только из Git, минуя геморрой с управлением помойкой файлов и ручного создания патчей.

Skull ★★★★★
()
Ответ на: комментарий от Skull

>Красота!

ненене. собрка пакетов в альте это просто полный пиздец. несколько руководств, все неполноценные. то ли дело наваять ебилд ;)

prizident ★★★★★
()
Ответ на: комментарий от tailgunner

> CLI в Mercurial более удобный (CLI git - это ужоснах и кошмар)

Что в нём кошмарного?

> есть приятные мелочи вроде локальных номеров ревизий

А что, номера коммитов Git слишком сложные?

> конфигурация Mercurial проще

Хм. Мне понадобилось настроить ~/.ssh/config и прописать имя, email и GPG-ключ. Что может быть проще?

> Симметрично.

А я не делал утверждений. Перечитайте мой пост ещё раз.

Skull ★★★★★
()
Ответ на: комментарий от Skull

>> Вот тут бы и перечислить преимущества, но... нет перечисления :D

> Преимущества http://www.altlinux.org/Gear и http://www.altlinux.org/Git.alt/Введение прямо проистекают из достоинств Git:

Мне не нужно рекламы Gear. После фразы "Всё же Mercurial IMHO не так распространён как Git. У нас в ALT Linux вообще сборка пакетов сделана только через Git" я лично ожидал сравнения Mercurial и Git.

А в рекламном блоке о Gear внимания заслуживает только "интеграция в VCS апстрима, в том числе и по истории" - здесь у Git дела обстоят лучше (по слухам).

tailgunner ★★★★★
()
Ответ на: комментарий от prizident

> ненене. собрка пакетов в альте это просто полный пиздец. несколько руководств, все неполноценные. то ли дело наваять ебилд ;)

Помойку для ebuild без VCS держите? Мне искренне вас жаль!

Skull ★★★★★
()
Ответ на: комментарий от tailgunner

На до же, до чего дошли Жаба-технологии, уже и git на Java пишут! Да еще назвали egit - ирландцы обидятся. :)

Bioreactor ★★★★★
()
Ответ на: комментарий от prizident

+много. Чего альтам не хватает, так это разумной документации, а не эти записки на манжетах по дороге в биореактор.

UserUnknown ★★★★★
()
Ответ на: комментарий от tailgunner

> я лично ожидал сравнения Mercurial и Git.

Не использовал Mercurial, не могу сравнить. Просто по работе как в ALT, так и апстриме, Mercurial не встречался ни разу. Вон, transifex (https://translate.fedoraproject.org/) работает с Git, куча очень больших проектов. Мне было достаточно посмотреть на то, кто использует Git, а кто — Mercurial, чтобы появились определённые выводы. Я против противопоставления Git и Mercurial, но лично отдаю предпочтение первому.

Skull ★★★★★
()
Ответ на: комментарий от UserUnknown

> Чего альтам не хватает, так это разумной документации, а не эти записки на манжетах по дороге в биореактор.

Есть такое. Но положение исправляется. Чего Вы такой злой? Девушка бросила?

Skull ★★★★★
()
Ответ на: комментарий от Skull

Нет, просто намучался и теперь упоминание альтов вызывает негатив :)

Не обращайте внимания - пройдёт.. наверное.

UserUnknown ★★★★★
()
Ответ на: комментарий от Skull

> Мне было достаточно посмотреть на то, кто использует Git, а кто — Mercurial, чтобы появились определённые выводы

Собственно, об этом и речь. Но мне лично распространенность системы важна мало, в отличие от ее удобства.

tailgunner ★★★★★
()
Ответ на: комментарий от Skull

>Помойку для ebuild без VCS держите? Мне искренне вас жаль!

прежде чем делать выводы, нужно дождаться ответа. тот оверлей что я мейнейню сейчас использует svn, планируется переход на гит. как можно держать оверелй без vcs я себе просто не представляю. после того как я не так давно узнал о силе git init, то теперь использую его везде. даже субтитры для аниме в нем храню. не говоря о всяких етс, хом и пр.

prizident ★★★★★
()
Ответ на: комментарий от prizident

дефолтное форматирование на лоре просто ужас :(

prizident ★★★★★
()
Ответ на: комментарий от UserUnknown

> Не обращайте внимания - пройдёт.. наверное.

Заварите корней валерианы — говорят, помогает.

Skull ★★★★★
()
Ответ на: комментарий от mqspi

> К слову говоря, этот самый transifex разрабатывается как раз с помощью mercurial.

Неудивительно, судя по его корням (Python). Только вот используется он для Git-репозиториев.

Skull ★★★★★
()
Ответ на: комментарий от prizident

> прежде чем делать выводы, нужно дождаться ответа.

Прощу прощения.

Skull ★★★★★
()
Ответ на: комментарий от mx_

> http://nathanj.github.com/gitguide/tour.html ( An Illustrated Guide to Git on Windows )

Хммм... я вообще-то git люблю и больше с ним знаком, но это руководство мне поздно попалось на глаза. К счастью я пока еще на стадии выбора VCS для работы, и у меня коллега - виндузятник... Подумаю на счет гита...

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

На сколько стабильный и удобный плагин под Eclipse для Mercurial?

Для Git плагин пока не юзабелен совсем :(

PS
Git-GUI тоже крив до невозможности.

Yilativs ★★★★
()
Ответ на: комментарий от Skull

>Для меня начать работать с Git оказалось гораздо проще, чем с CVS и SVN.

++
Сам недавно озаботился выбором VCS для хранения конфигов. Сначала попробовал RCS, но дойдя до конфигов FVWM'а понял, что надо чтото более удобное. Попробовал SVN, но так и не понял идеологию его хранилища (да да, ниасилил). После этого почитал гитовский ман (точнее его html версию) и gittutorial, все сразу стало ясно и понятно. Сейчас просто в восторге от него.

fat_angel ★★★★★
()
Ответ на: комментарий от tailgunner

>Это тот, где Git реализован на Яве? %)
Точно так же как и SVN.

Только SVNKit работает за частую быстрее и безглчней чем JavaHL(он через бинарники svn работает)

А вот гитовый плагин работает мягко говоря плохо.
Лучше чем Git-GUI но все равно мало юзабелен.

Yilativs ★★★★
()

Традиционно:
- Распределённые VCS не нужны. По крайней 95% тех, кто их исползует.
Неполхая критика http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot
Критикуется не сам bitkeeper а сама модель разработки применительно к линуксу.
Для Ъ
* Limited development speed: even with the best tools, a single integrator can only achieve a certain level of throughput.

* Single point of failure: if the single integrator of a branch suffers an accident, goes on vacation, or simply burns out, development is disrupted until a new integrator can be selected and comes up to speed.

* Opinionated maintainers: it is a rare individual who is always right. For instance, the mainline Linux kernel does not contain a kernel debugger because Linus won't allow it. "I don't think kernel development should be 'easy'. I do not condone single-stepping through code to find the bug." [2]

* Limited filtering: work done by (or approved by) an area maintainer is only subject to review by the branch integrator, and such review may be cursory or nonexistent. Of course, anyone can review all the changes that go into a branch, but only two people are in a position to say "no, this change does not meet our standards; it cannot go in" and make it stick.

grim ★★☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.