Pull to refresh

Comments 45

Прошу прощения, если прочитал по диагонали и не заметил, но. Не рассказано самое интересное — staging area. Во многих системах контроля версий индекса нет. То, как вы описали команду add скорее похоже на mercurial.


В git никакие изменения сразу не регистрируются. Если вы изменили файл и запустили git commit, волшебство не произойдет. Вообще любые изменения нужно регистрировать git add — и создание, и изменение, и удаление файла. Изменения, добавленные git add — это и есть staging area. При это один файл может и быть, и не быть в staging area одновременно. Например (в консоли):


$ vi file.txt
$ git add file.txt
$ vi file.txt
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
        modified: file.txt

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
        modified: file.txt
$ git commit # будет закоммичен первый файл

Ну и естественно можно изменения из staging area удалить.

UFO landed and left these words here
значит, вы используете Git даже не в полсилы ))) особенно, с учётом
часто бывает на последней стадии передумывается и решается изобразить два коммита, а не один, а git add уже сделан на все

с Git это разруливается не легко, а очень легко:
UFO landed and left these words here
по-моему, Ваш способ не работает, когда нужно добавить лишь часть изменений из одного файла (я про git add --patch)

кстати, про
Сделав git add, Вы на git status видите неверную инфу, при том что оно еще не закоммичено

лично я предпочитаю смотреть git diff
Стесняюсь спросить, а чем новых сотрудников не устраивают существующие учебники по git? Например, на git-scm (не сочтите за рекламу) есть версия на русском языке, доходчиво, с картинками.
Почему-то этот момент упущен в мотивировочной части.

Как ведёт себя гит с бинарными файлами? .pad, .jpg, .Avi и так далее? Есть ли специализированные системы контроля версий для не текстовых файлов?

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

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

Прошу прощения, но чем эта статья полезней других заметок в стиле «learn X in Y minutes»?
Статей, в которых бы последовательно объяснялись идеи git (причём так, чтобы было понятно непрограммистам) не нашли. Если знаете такие, пришлите, пожалуйста, ссылки.
Ну вот прям так, чтоб трехлетнему ребенку пояснить, да еще и чтоб он все понял — я и сам не встречал.
Но простого howto должно быть достаточно. Не?
Имхо, для непрограммистов нужны туториалы как пользоваться github for desktop или gitkraken. Им кнопочки нажимать нужнее, чем понимать что происходит под капотом.
Чуть выше я писал про git-scm.com/book/ru/v2
Очень просто получить «быстрый старт» с чего-то, имеющего вменяемый и доступный GUI, типа SmartGit. Я вот начинал знакомство с системы контроля версий Mercurial, к которой по умолчанию прилагается неплохой такой GUI-клиент TortoseHg. Не пир духа, но, ИМХО, гораздо вменяемее «изкоробочного» git gui. ЕМНИП, покорило то, что диффы представлены в максимально наглядном (читай «и дураку понятном») виде, можно поправить файлы оттуда же перед коммитом, и, что особо ценно, можно откатить изменения одной-двух строк, а не всего файла.
Когда я начал работать там, где Git был стандартом (и особо в чести была консольная работа с ним), то — после неудачного эксперимента по спариванию разных систем контроля версий при помощи бриджей (ещё то извращение, бррр!) — я долго выл на тему «изверги, неудобно же без визуальных плюшек!».
А потом мне дали SmartGit. Он покрывает 95% джуновских потребностей в Гите и 60-70% потребностей сеньора. Сложные и замороченные вещи в нём делать сложно, зато простые вещи — очень и очень просто. Как показал опыт — новые бойцы втягиваются в Гит где-то после часа инструктажа по интерфейсу SmartGit, и новых проблем (при условии адекватности бойца) он сам по себе создавать не склонен. Рекомендую!

Блин, где? Где вы до сих пор берете сотрудников которые работают с SVN а не с git?
Я последний раз видел SVN когда с него мигрировали в 2011 году, после этого только git. Не, я понимаю дизайнеры, но их же обучат, у них программеры под боком, всегда найдется кто-то кто поможет если что.

Встречаются и с CVS, и не пользовавшиеся SVN и GIT. Откуда — если привычный неосновной инструмент работает хорошо — зачем его менять ?

Проверьте, их много… Это и энерпрайз, с огромным количеством коммитов и нежеланием тратить ресурсы на переезд на новую скв, и параноики, желающие иметь полный контроль над единственным репозиторием, и просто устаревшие и полу-актуальные проекты, которым это просто не нужно.
Да что там… Я сам лично считал, что это просто хипстерская распиаренная поделка, пока не пришлось по работе изучить hg. И после личного контакта я понял, как ошибался, и побежал изучать git и переводить свои проекты с svn на него :)
У нас SVN используется, перехода на git не предвидится — нет нужды в децентрализованной модели.

Вам скоро будет радость — SVN начнет поддерживать локальные коммиты. Я, к сожалению, не дождался — сервис заломил приличные деньги за SVN репозитарии и я принудительно ушел на GIT (к моему удивлению он на амазоне бесплатный).

Так для дизайнеров у SVN есть киллер-фича — блокировка файла. Чтобы правки бинарников не перекрывали друг друга.

Главный совет забыли: сразу найти человека, которому будете задавать вопросы.


Наука умеет много гитик… То есть тьфу, git имеет много возможностей — и не меньше способов выстрелить себе в ногу. К примеру, я в начале пользования умудрился потерять ветку. Совсем — так что при просмотре дерева ревизий её не было. К счастью, немного гугления, чтения док — и я освоил git reflog и шаманство с git branch (после mercurial с его "history is permanent and sacred" это был шок).

В Mercurial rebase и другие команды модификации истории есть давным-давно.

Знаю, даже пользуюсь дома (хотя и с осторожностью, обычно предпочитая бранчи). Но даже с учётом этих команд — mercurial заметно проще, а "святость истории" навязывается гораздо сильнее, чем в git.

Сразу скажу, что я не уверен в чистоте своих впечатлений, но вообще понимание git мне пришло с пониманием того что никакого чуда нет, в конце концев рекомендуемая модель (GIT_Succinctly стр 58) — Integrator Workflow, когда хоть изменения пулятся в общий паблик репоситорий, мержатся они должны в другом «архитекторском» и только «архитектор» будет мержить изменения в «публичный» паблик.

Правда как они перенаправляются из публичного в архитекторский — до сих пор не понятные мне детали (объясните?)… Но главное, что «по краям» возможности системы очерчены.

Отпишусь, как новичёк по данной теме.
Смотрел
[x] на Ютьюбе несколько видеороликов, по 5 минут,
[x] несколько статей прочитал.
Уже несколько дней работаю с гитом через консоль, хотя ранее использовал GUI-software.


$ git branch
* develop
  feature
  hotfixes
  master
  release

А за актуальность темы спасибо, буду ждать продолжения.

Вполне неплохой мануальчик для начинающих, буду и сюда отправлять тех, кто хочет, чтобы за ручку привели и книжку дали. В коллекцию полезных ссылок добавлю: http://ohshitgit.com/ как разрулить частые «ой, блин» в гите.
О, может кто подскажет.
Я использую GIT-GUI. Вот наделал я набор коммитов. И хочу вернуться назад к какому-то варианту. Выбираю репозиторий->показать историю ветви. А вот дальше, если я выберу что-либо и нажму установить ветвь на это состояние, то файлы изменяются, только если сделать вариант «жёсткий». Но при этом все коммиты ветки после выбранного коммита нафиг теряются. Как же тогда делать в git-gui такой переход?
Ну и второй вопрос — нет ли у кого работающего GIT под QNX? Тот, что я видел не работал нифига. Команды ничего не делают.
Спасибо.
Как же тогда делать в git-gui такой переход?

посмотрите «историю ВСЕХ ветвей» ))
Так я её и смотрю (у меня, допустим, одна ветвь)). А вот как переместиться на позицию, переписав все рабочие файлы в каталоге и не потерять все изменения после этой позиции?
а, так у вас одна ветка!
теперь я, кажется, понял, почему у вас «пропадает» )
(кстати, так, для информации, однажды сделанный коммит уже не пропадёт, его, как правило, можно «восстановить», даже если кажется, что он «пропал»)
на «низком» уровне — коммиты в Git — направленный граф, а ветка — лишь УКАЗАТЕЛЬ на коммит
Git по умолчанию показывает лишь коммиты, которые можно увидеть через именованные ветки/сущности: это локальные ветки, удалённые (remote) ветки и метки (tags)
если на коммит (или коммиты после него) нет «указателя», то такой коммит становится «подвисшим» (dangling), и увидеть его — уже не так просто )
вам стоит только перед сменой ветки в предыдущее состояние создать ветку на том же коммите, к которому вы хотите потом вернуться, чтобы после сброса первой ветки, у вас осталась вторая ветка, которая бы указывала на старый коммит

З.Ы. и раз уж Вы пользуетесь Git, прочтите Pro Git
а в лёгкой форме — habrahabr.ru/company/intel/blog/344962
и освойте командную строку, в ней бы Вам не пришлось сбрасывать ветку в состояние предыдущего коммита, чтобы получить рабочую копию на тот момент, достаточно было бы
git checkout <commit-id>, а gitk (который из Git GUI вызывается, показывая Вам «историю ветвей») не умеет делать checkout без ветки…
Спасибо за ответ. :)

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


Надо же… Я такого не ожидал. В моём представлении такая «машина времени» должна быть элементарна, как и переход с ветки на ветку.

Pro Git я читал кусочками, но вот так с ходу решение проблемы я не отыскал.
Что касается консоли, я всё же предпочитаю графический интерфейс. Я пробовал ещё Tortoise Git (ну или как-то так) — увы, с ней компьютер резко стал притормаживать при работе с каталогами в том же проводнике. Снёс нафиг. :)
Я с Git-GUI сейчас пытаюсь понять, как перевести конечный результат ветки рефакторинга в master, чтобы они не объединились целиком в каждом коммите ветки (как делает этот самый git-gui).
Я такого не ожидал. В моём представлении такая «машина времени» должна быть элементарна, как и переход с ветки на ветку.

а так оно и есть — это элементарно:
$ git checkout <commit-id>
$ git checkout <branch-1>

просто то, что Вы делали — не «переход с ветки на ветку» (= git checkout), а «сброс ветки» (= git reset), а это разные операции и ожидаемые результаты их разные, и то, чтобы от reset ждали результата checkout — не проблема Git, а Вашего понимания, того, что происходит под капотом GUI (за это я не люблю GUI, да ещё русифицированные; так, например, в том gitk «Установить ветвь на это состояние» в оригинале называется "Reset… branch to here", чтобы как бы намекает...)
см. также Раскрытие тайн reset

У меня коллега, тоже любитель GUI, использует GitExtensions…
А, вот оно что! :)

GitExtensions


Спасибо, скачаю.
Попробовал Git Extensions. Замечательно работает! :) Всё просто и понятно. И ветки легко слились. :) Одно только пока не понял — как его заставить отображать русские комментарии к коммитам. Для git gui пособие было — я по нему всё и настроил. А для extensions пока не пойму.
а в каком виде они отображаются?
Как квадратики. Но я обновил сам GIT и всё заработало. :)
А Source Tree не подходит — оно на XP (да, я её люблю :) ) не идёт.
Идиотский вопрос а чем Git отличаеться от github?
Сам Git это системами контроля версий а github это облачный репозиторий который работает на Git?
Git и Github — это как котлета и кот, который её ест…
облачный репозиторий + постоянно наращиваемый web аpp (в git нет issues, releases и т.д)
Примерно тем же, чем отличается email и Mail.ru.

Промахнулся, ответил ниже

Гит – система контроля версий. Им можно пользоваться без гитхаба вообще. Создаете локальный репозиторий и работаете. Можно потом удаленный репозиторий добавить в общей папке на сервере.
Гитхаб – сервис для командной разработки. Там много всего, но в том числе есть и гитовый репозиторий. Некоторые операции можно делать прямо в браузере, но для полноценной работы нужен и локальный гит клиент.
Гитхаб не единственный в своем роде, есть еще гитлаб и битбакет (самые популярные альтернативы).

Мне, как человеку, который только начинает пользоваться Git'ом, статья показалась полезной, спасибо. Хочу вторую часть.

Ещё было бы неплохо краткое сравнение различных программ, имеющих гуевые версии — для тех кто консоль не любит.
В качестве комментария по GUI для Git. Если строка не устраивает. Сам я пользуюсь SourceTree от Atlassian c примочкой Git Flow.

image

Мне нравится. Вот тут популярно, что это за зверь. У Hg есть удобный TortoiseHg, а SourceTree поддерживает и Hg и Git.

Only those users with full accounts are able to leave comments. Log in, please.