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 удалить.
часто бывает на последней стадии передумывается и решается изобразить два коммита, а не один, а git add уже сделан на все
с Git это разруливается не легко, а очень легко:
Почему-то этот момент упущен в мотивировочной части.
Как ведёт себя гит с бинарными файлами? .pad, .jpg, .Avi и так далее? Есть ли специализированные системы контроля версий для не текстовых файлов?
Можно посмотреть в сторону файловых систем с де-дубликацией для эффективного хранения повторяющихся блоков данных (если они есть).
Для бинарных файлов в гит есть расширение Git LFS, в первую очередь направлено на оптимизацию хранения больших файлов, типа видео, аудио, изображений и т.д.
Но простого howto должно быть достаточно. Не?
Имхо, для непрограммистов нужны туториалы как пользоваться github for desktop или gitkraken. Им кнопочки нажимать нужнее, чем понимать что происходит под капотом.
Когда я начал работать там, где Git был стандартом (и особо в чести была консольная работа с ним), то — после неудачного эксперимента по спариванию разных систем контроля версий при помощи бриджей (ещё то извращение, бррр!) — я долго выл на тему «изверги, неудобно же без визуальных плюшек!».
А потом мне дали SmartGit. Он покрывает 95% джуновских потребностей в Гите и 60-70% потребностей сеньора. Сложные и замороченные вещи в нём делать сложно, зато простые вещи — очень и очень просто. Как показал опыт — новые бойцы втягиваются в Гит где-то после часа инструктажа по интерфейсу SmartGit, и новых проблем (при условии адекватности бойца) он сам по себе создавать не склонен. Рекомендую!
Блин, где? Где вы до сих пор берете сотрудников которые работают с SVN а не с git?
Я последний раз видел SVN когда с него мигрировали в 2011 году, после этого только git. Не, я понимаю дизайнеры, но их же обучат, у них программеры под боком, всегда найдется кто-то кто поможет если что.
Встречаются и с CVS, и не пользовавшиеся SVN и GIT. Откуда — если привычный неосновной инструмент работает хорошо — зачем его менять ?
Да что там… Я сам лично считал, что это просто хипстерская распиаренная поделка, пока не пришлось по работе изучить hg. И после личного контакта я понял, как ошибался, и побежал изучать git и переводить свои проекты с svn на него :)
Главный совет забыли: сразу найти человека, которому будете задавать вопросы.
Наука умеет много гитик… То есть тьфу, git имеет много возможностей — и не меньше способов выстрелить себе в ногу. К примеру, я в начале пользования умудрился потерять ветку. Совсем — так что при просмотре дерева ревизий её не было. К счастью, немного гугления, чтения док — и я освоил git reflog и шаманство с git branch (после mercurial с его "history is permanent and sacred" это был шок).
Правда как они перенаправляются из публичного в архитекторский — до сих пор не понятные мне детали (объясните?)… Но главное, что «по краям» возможности системы очерчены.
Отпишусь, как новичёк по данной теме.
Смотрел
[x] на Ютьюбе несколько видеороликов, по 5 минут,
[x] несколько статей прочитал.
Уже несколько дней работаю с гитом через консоль, хотя ранее использовал GUI-software.
$ git branch
* develop
feature
hotfixes
master
release
А за актуальность темы спасибо, буду ждать продолжения.
Я использую 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 это системами контроля версий а github это облачный репозиторий который работает на Git?
Гит – система контроля версий. Им можно пользоваться без гитхаба вообще. Создаете локальный репозиторий и работаете. Можно потом удаленный репозиторий добавить в общей папке на сервере.
Гитхаб – сервис для командной разработки. Там много всего, но в том числе есть и гитовый репозиторий. Некоторые операции можно делать прямо в браузере, но для полноценной работы нужен и локальный гит клиент.
Гитхаб не единственный в своем роде, есть еще гитлаб и битбакет (самые популярные альтернативы).
Ещё было бы неплохо краткое сравнение различных программ, имеющих гуевые версии — для тех кто консоль не любит.
Мне нравится. Вот тут популярно, что это за зверь. У Hg есть удобный TortoiseHg, а SourceTree поддерживает и Hg и Git.
Git: советы новичкам – часть 1