Комментарии 85
НЛО прилетело и опубликовало эту надпись здесь
Похоже на Intellij IDEA с темой Dracula
У sublime text есть сайдбар слева! Он появляется, если открыть в редакторе папку, как-то так:
Возможно, как-то его можно и из интерфейса показать.
Но на фото не sublime.
subl ~/dev/project
Возможно, как-то его можно и из интерфейса показать.
Но на фото не sublime.
Возможно, как-то его можно и из интерфейса показать.
View -> Side bar -> Show side bar
НЛО прилетело и опубликовало эту надпись здесь
Цвет задается темой, так что это тут ни при чем.
Project -> Add folder to Project…
>саблаймовский сайдбар показывает только открытые файлы
Чушь. Сайдбар показывает также и папки и другие файлы в директории.
Например если открывать не файлик а папку.
Чушь. Сайдбар показывает также и папки и другие файлы в директории.
Например если открывать не файлик а папку.
Плюс можно поставить плаг Sidebar Enchantments — добавляет кучу полезного функционала в сайдбар.
github.com/titoBouzout/SideBarEnhancements
github.com/titoBouzout/SideBarEnhancements
Atom? atom.io/
Скорее всего Atom с isotope-ui или чем-то подобным atom.io/themes/isotope-ui
похоже на саблайм разбитый на 2 окна
envelopsolutions.com/ — оригинал картинки похоже что отсюда. Можно попробовать им написать, узнать.
На Atom с Seti UI похоже atom.io/themes/seti-ui
Это точно Atom. Характерная иконка корня проекта, характерная подсветка дерева файлов, характерная оранжевая иконка незакомиченных изменений внизу справа.
У Саблайма статус бар на все окно, а Atom сайдбар на всю высоту, и под ним нет статус бара. Тема стандартная темная.
У Саблайма статус бар на все окно, а Atom сайдбар на всю высоту, и под ним нет статус бара. Тема стандартная темная.
Atom 100%
Почему вы думаете, что это может быть не Sublime!? Для примера мой интерфейс Sublime:
> Много раз я ломал репозиторий чудовищным образом, делая неверные мерджи и стирая не те данные, но ни разу не было случая, чтобы данные были потеряны или VCS оставила бы меня один на один с руинами.
Видимо автор не сталкивался с «error: sha1 mismatch», посмотрел бы я как он это чинить будет :(
Видимо автор не сталкивался с «error: sha1 mismatch», посмотрел бы я как он это чинить будет :(
Да даже detached head не так просто починить бывает.
У нас в команде наступило счастье, когда мы стали использовать SourceTree. Репозиторий стал ломаться реже, чем при использовании консоли.
У нас в команде наступило счастье, когда мы стали использовать SourceTree. Репозиторий стал ломаться реже, чем при использовании консоли.
Ээээ, с каких пор detached head нужно «чинить»? И да, SourceTree хорош, но проще и понятнее GitHub ничего нет. Самое то для новичков. Я его использую как монитор диффов и ознакомления с историей, а командую всё равно в консоли — очень быстро и функционально, хоть и сам признаю что команды иногда совсем не соответствуют тому чего от них ожидаешь.
Для консоли зело рекомендую tig.
Крайне редко пользуюсь графическими инструментами, но без него работу практически не мыслю.
Крайне редко пользуюсь графическими инструментами, но без него работу практически не мыслю.
Со своей стороны порекомендую git-forest из набора github.com/jwiegley/git-scripts
Тоже не мыслю без него работы, настолько привык :)
Тоже не мыслю без него работы, настолько привык :)
Сталкивался несколько раз с людьми, которые принципиально с гитом работали из консоли.
Так вот от них постоянно косяки шли.
То файлик не добавят, то ошибку пропустят, то закомитят лишнее и т.д.
Не знаю почему так.
Все остальные юзали различные GUI и никаких проблем.
Да и самому, перед коммитом, так сказать «окинуть взглядом то что комитишь» гораздо проще из GUI.
Того же SourceTree или прямо из IDEA.
Много таких ошибок вылезает именно в этот момент.
Так вот от них постоянно косяки шли.
То файлик не добавят, то ошибку пропустят, то закомитят лишнее и т.д.
Не знаю почему так.
Все остальные юзали различные GUI и никаких проблем.
Да и самому, перед коммитом, так сказать «окинуть взглядом то что комитишь» гораздо проще из GUI.
Того же SourceTree или прямо из IDEA.
Много таких ошибок вылезает именно в этот момент.
Готов поспорить на деньги, что этих людей было у вас от двух до трех, и теперь вы по ним судите всех «консольщиков».
Так вот от них постоянно косяки шли.
Звучит, как неплохое начало холивара. Уверен, что забыть добавить файл можно и в GUI, это скорее вопрос внимательности.
а вот предположим такую ситуацию — разворачиваем проект на сервере где нет gui?
можно придумать более сложную задачу чем просто git clone и еще ограничить ситуацию по времени — надо сделать это позавчера.
и что делать человеку который привык к кнопочкам?!
после пары таких ситуаций плюнул на все gui клиенты и научился работать в консоли
gui бывает пользуюсь чтобы окуинуть взглядом дерево коммитов, но не более.
можно придумать более сложную задачу чем просто git clone и еще ограничить ситуацию по времени — надо сделать это позавчера.
и что делать человеку который привык к кнопочкам?!
после пары таких ситуаций плюнул на все gui клиенты и научился работать в консоли
gui бывает пользуюсь чтобы окуинуть взглядом дерево коммитов, но не более.
Принципиально работаю из консоли. Никогда ничего не ломаю, а проблемы всегда идут от тех, кто использует GUI. :)
По-моему тут скорее вопрос о наглядности представления состояния репозитория.
Например, я с гитом работаю почти всегда из консоли, но я подобрал для себя несколько строго консольных инструментов, которые прекрасно выполняют функцию визуализации и благодаря им я всегда максимально в курсе в каком состоянии находится репозиторий. И это дает меньше возможностей случайно накосячить, наверное не сильно слукавлю, сказав, что за последние пару лет количество инцидентов нулевое.
С GUI упор делается на визуализацию, поэтому в принципе состояние репозитария более понятно пользователю. Но при этом GUI зачастую прячет многие полезные команды либо под слой абстракции, либо вообще. И это существенный минус, потому что в любом случае приходится лезть в консоль, чтобы сделать что-либо менее тривиальное, чем add-commit-push-pull.
Например, я с гитом работаю почти всегда из консоли, но я подобрал для себя несколько строго консольных инструментов, которые прекрасно выполняют функцию визуализации и благодаря им я всегда максимально в курсе в каком состоянии находится репозиторий. И это дает меньше возможностей случайно накосячить, наверное не сильно слукавлю, сказав, что за последние пару лет количество инцидентов нулевое.
С GUI упор делается на визуализацию, поэтому в принципе состояние репозитария более понятно пользователю. Но при этом GUI зачастую прячет многие полезные команды либо под слой абстракции, либо вообще. И это существенный минус, потому что в любом случае приходится лезть в консоль, чтобы сделать что-либо менее тривиальное, чем add-commit-push-pull.
Я сталкивался много раз с обратной ситуацией (сам работаю с git через консоль), те кто работают через GUI (SourceTree) не раз ломали дерево коммитов и не могли самостоятельно починить во многих случаях.
Те кто используют консольный вариант, как правило, глубже понимают как работает git (в данном случае я правда скорей всего сужу по себе в большей степени, ибо большинство знакомых программистов сидят на винде и не любят консоль в принципе), т.к. официальная документация хорошо раскрывает все внутренности (с примерами в консоли), по которой и стоит изучать git.
Те кто используют консольный вариант, как правило, глубже понимают как работает git (в данном случае я правда скорей всего сужу по себе в большей степени, ибо большинство знакомых программистов сидят на винде и не любят консоль в принципе), т.к. официальная документация хорошо раскрывает все внутренности (с примерами в консоли), по которой и стоит изучать git.
Мне кажется дело в том, что и они, и вы не умеете работать с git. Гуй страхует, а используя консоль легче выстрелить себе в ногу.
Поэтому вопрос только в опыте.
Со своей стороны могу противопоставить ситуацию, когда я периодически исправляю (в консоли, поскольку gui не дает полноценного контроля) косяки разработчиков, которые «что-то не то нажали» в tortoisegit.
Поэтому вопрос только в опыте.
Со своей стороны могу противопоставить ситуацию, когда я периодически исправляю (в консоли, поскольку gui не дает полноценного контроля) косяки разработчиков, которые «что-то не то нажали» в tortoisegit.
Один раз словили этот sha1 mismatch на сервере репозитория. Ни кто не мог сделать fetch. Запросил поломанные файлы у разработчика, скопировал поверх повреждённых, после чего всё заработало. Но времени, конечно, на это я потратил не мало.
А уж как легко потерять данные при использовании «push -f» :-/ (привычка hg-шника, который твёрдо уверен, что DCVS — это штука, которая ни при каких условиях не должна терять данные неявно).
Данные/коммиты некоторое время остаются в reflog-е откуда их можно достать обратно.
>неявно
-f == --force
не знаю, как ещё более явно дать понять.
-f == --force
не знаю, как ещё более явно дать понять.
«push -f» не всегда можно сделать. Например, мы не даём такое делать в интеграционный репозиторий.
Как уже заметили, "-f" это явный способ сказать — я знаю, что делаю что-то очень необычное, и хорошо понимаю к чему это может привести.
Как уже заметили, "-f" это явный способ сказать — я знаю, что делаю что-то очень необычное, и хорошо понимаю к чему это может привести.
Можно по привычке топором по ноге себе стукнуть, но это не значит, что топор так плох. Скорее, если при этом что-то оттяпалось, значит, как раз хорош.
Но и это не проблема для git.
Если что-то перезатерлось, значит оно там было, а значит его можно там достать из reflog.
Но, конечно, это должен быть исключительный случай.
Но и это не проблема для git.
Если что-то перезатерлось, значит оно там было, а значит его можно там достать из reflog.
Но, конечно, это должен быть исключительный случай.
Откуда опять reflog?
Хорошесть топора определяется не тем, как легко он что‐то оттяпывает. А тем, как легко им оттяпать только то, что нужно. И это всегда баланс между «его даже взять нельзя без подробного пересказа техники безопасности с последующим подписанием бумаги о том, что я с нею ознакомлен» и «я его уронил, так он половину Земли оттяпал». То, где находится баланс в git меня не устраивает. И не только меня.
git push -f легко затрёт данные, которых в вашем reflog’е никогда не были, а чужой (к примеру, reflog GitHub’а) может быть не доступен.Хорошесть топора определяется не тем, как легко он что‐то оттяпывает. А тем, как легко им оттяпать только то, что нужно. И это всегда баланс между «его даже взять нельзя без подробного пересказа техники безопасности с последующим подписанием бумаги о том, что я с нею ознакомлен» и «я его уронил, так он половину Земли оттяпал». То, где находится баланс в git меня не устраивает. И не только меня.
И я за много лет использования не ломал репозитория ни разу и ни разу не делал хедшот, даже когда серьезно ошибался и удалял все изменения и в локальном и в удаленном репозитории, все равно была возможность восстановить мои коммиты из кэша удаленных коммитов.
Пользуюсь исключительно консолью — так точно понимаешь, что именно ты делаешь. Всякие гуи работают с git за тебя и «контроль на кончике пальцев» теряется.
То о чем автор пишет очень точно описывает суть работы с git — как только ты понял принципы его работы никаких сложностей с ним больше не возникает не смотря на не самую стройную систему комманд.
Порой удивляюсь, когда общаюсь со своими разработчиками и оказывается, что одно и то же действие мы делаем совершенно по разному, приходя к одному и тому же результату.
Пользуюсь исключительно консолью — так точно понимаешь, что именно ты делаешь. Всякие гуи работают с git за тебя и «контроль на кончике пальцев» теряется.
То о чем автор пишет очень точно описывает суть работы с git — как только ты понял принципы его работы никаких сложностей с ним больше не возникает не смотря на не самую стройную систему комманд.
Порой удивляюсь, когда общаюсь со своими разработчиками и оказывается, что одно и то же действие мы делаем совершенно по разному, приходя к одному и тому же результату.
Note: «некорректные разрешения» лучше перевести как «некорректные права на файлы». Слово «разрешение» имеет другой смысл в русско-айтишном, не связанное с permission.
> Даже Mercurial сдался и теперь предупреждает пользователя о том, что создание именованной ветки — не лучшая идея.
А что не так с именованными ветками?
А что не так с именованными ветками?
В обсуждении оригинальной статьи на reddit задали точно такой же вопрос. срач обсуждение можно почитать по ссылке :).
НЛО прилетело и опубликовало эту надпись здесь
Например, на Bitbucket для Mercurial-репозиториев реализовали pull requests через именованные ветки, и это всех бесит, так как такой подход захламляет репозиторий никому ненужными ветками, потому что их нельзя удалить. Именованные ветки были сделаны вообще не для этого, они не являются временными. Как можно было сделать на них систему PR?!
Вот тут bitbucket.org/site/master/issue/6705/cant-create-pull-request-from-hg-bookmark 121 votes за то, чтобы сделать поддержку PR из bookmarks. Но Atlassian по факту давно забил на поддержку Mercurial.
Вот хороший комментарий из обсуждения issue:
Возможно, автор имел в виду что-то подобное.
Вот тут bitbucket.org/site/master/issue/6705/cant-create-pull-request-from-hg-bookmark 121 votes за то, чтобы сделать поддержку PR из bookmarks. Но Atlassian по факту давно забил на поддержку Mercurial.
Вот хороший комментарий из обсуждения issue:
i'm curious about one thing: as far as i understand it, the workflow endorsed by bitbucket (named branch per pull request) goes straight against the mercurial documentation: «don't treat branch names as disposable», so let's say the mercurial authors know their code, and creating a branch name for every pull request is «using it wrong». where will i get support if mercurial hits some performance or correctness limits thanks to a few thousand closed branches?
Возможно, автор имел в виду что-то подобное.
НЛО прилетело и опубликовало эту надпись здесь
Гитлаб тоже запрещает? Он так же позволяет создавать бесплатно приватные репозитории.
Попробуйте gogs.io, если вам нужен веб-гуй и gitolite.com если не нужен.
Попробуйте scm-manager. Достойная внимания реализация. Обновляется, гит/свн/меркуриал, плагинов гора.
Разворачивается за 15 минут.
Разворачивается за 15 минут.
Мне вот что в гите не нравится:
Удалить ветку: git branch -d
Удалить remote ветку: git push origin :branch_name
Для меня эти команды выглядят как одно и тоже.
Хотя конечно, я уже привык и все ему прощаю
Удалить ветку: git branch -d
Удалить remote ветку: git push origin :branch_name
Для меня эти команды выглядят как одно и тоже.
Хотя конечно, я уже привык и все ему прощаю
Честно говоря, эти команды совсем не одно и тоже, если посмотреть на них под другим углом. Первая команда работает с локальным состоянием, вторая пушит изменения в удаленный (remote) репозиторий. Команда push в общем виде условно имеет формат
git push origin src:dst. Отсутствие «источника» (src) воспринимается обрабатывающим сервером как замена ветки (указателя на коммит) на пустоту (null), то есть удаление.Тоже как первый раз смотрел, как удалить (физически) ветку в удаленном (дистанционно) репозитории, был в недоумении от синтаксиса.
Но, как раз тут и проявляется прозрачность команд по отношению к логике работы.
Как только вы поймете, что делается этими командами на самом деле, вопросы отпадут сами собой.
Но, как раз тут и проявляется прозрачность команд по отношению к логике работы.
Как только вы поймете, что делается этими командами на самом деле, вопросы отпадут сами собой.
даже не задумываясь о неконсистентности
Извините, пожалуйста:
inconsistence
Существительное
непоследовательность
несовместимость
несоответствие
необоснованность
несогласованность
НЛО прилетело и опубликовало эту надпись здесь
Этот, как его — произвол переводчика, вот :).
Википедию тоже пишут люди. Видимо, любящие кальку. Кто-то и «дигитальный» использует вместо «цифровой».
Современный толковый словарь русского языка Ефремовой
Консистентный
ТолкованиеПеревод
Консистентный
консисте́нтный
прил.
соотн. с сущ. консистенция, связанный с ним
Толковый словарь Ефремовой. Т. Ф. Ефремова. 2000.
.
Синонимы:
пластичный
Современный толковый словарь русского языка Ефремовой
Консистентный
ТолкованиеПеревод
Консистентный
консисте́нтный
прил.
соотн. с сущ. консистенция, связанный с ним
Толковый словарь Ефремовой. Т. Ф. Ефремова. 2000.
.
Синонимы:
пластичный
В тред врывается git submodule! В широких кругах более известен как «pain in the ass». 9 шагов(!) чтобы переместить, 7 шагов чтобы удалить.
Да, в последних версиях попроще.
Да, в последних версиях попроще.
Поэтому всегда советую субмодулями не пользоваться, если нет хороших причин, по которым он становится нужен.
В документации mercurial тоже советуют использовать свои subrepos, только если без них нельзя. (http://mercurial.selenic.com/wiki/Subrepository: «This is considered a feature of last resort.»)
Настоящие гуру делают
git init внутри папки .git и хранят состояние репозитория в репозитории. Если сделать коммиты состояния репозитория перед сложными изменениями, то чтобы вы не сломали, в каком бы промежуточном состоянии не находились, всегда можно выполнить git reset --hard HEAD внутри папки .git и откатить весь репозиторий до рабочего состояния.
У гита есть проблема с дизайном, не надо пытаться искать в этом тайный смысл.
Вообще не разу в жизни не открывал консоль Git, всё делаю через PhpStorm. Поэтому поводов испытывать непреязнь у меня тоже нет.
Каким же надо быть задротом чтобы учить эти тупые, нелогичные команды и хвалиться этим. У меня есть в жизни дела поважнее.
Каким же надо быть задротом чтобы учить эти тупые, нелогичные команды и хвалиться этим. У меня есть в жизни дела поважнее.
«но ни разу не было случая, чтобы данные были потеряны» — странно это читать, когда GIT позволяет историю редактировать. Как мне кажется, в GIT легко сделать необратимые изменения, особенно если не до конца понимать, что именно ты делаешь.
При принятии решения использования гита для проекта я бы еще учитывал, на каких языках пишется проект. ИМХО гит неплох для скриптовых языков, но для низкоуровневых, типа си, с++, с# и т.п. он просто неудобен. К тому же стоит учитывать, что гит плохо работает с большими файлами (например, когда нужно корректировать модель в десятки мегабайт, то гиту может поплохеть).
А в чем разница между языками для гита и для его пользователя?
Ну да, поэтому он совершенно не подходит, например, для ядра linux в 16 млн строк кода. Подождите…
>модель в десятки мегабайт
мне кажется, у вас на проекте есть проблемы посерьёзнее, чем git.
мне кажется, у вас на проекте есть проблемы посерьёзнее, чем git.
Даже PSD хранил одно время — удобно в офисе скинуть, а дома работать, потом правда подсел на дропбокс и давно уже так не делал.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я не испытываю неприязни к Git: скрытая целостность