How to become an author
Search
Write a publication
Pull to refresh

Comments 52

Хобгоблин доставил неимовернейше :) Спасибо за перевод!
Total votes 17: ↑16 and ↓1+15
Присоединяюсь. Перевод отличный.
Total votes 3: ↑2 and ↓1+1
«Я учила Unix-путь...» >< Лучше было оставить Unix-way.
Total votes 4: ↑3 and ↓1+2
А можно для тех, кто не особо крут в Гите под каждый пунктом объяснение от К.О.?
Total votes 15: ↑15 and ↓0+15
Попробую.

Начнем с того, что тут все легкий наезд на git.

  1. «aliases that hide existing git commands are ignored». При этом ошибка не выводится.
  2. Комментарии излишни.
  3. В идеологии git подробное хранение истории. При этом веткам уделено настолько мало внимания, что выяснить в какой ветке внесено определенное изменение — не тривиальная задача.
    Честно говоря я не уверен, что ветки удаляются не бесследно (а удаление веток после слияния предполагается идеологически).
  4. Несогласованность параметров различных команд. Одинаковые действия с различными сущностями не имеют ни чего общего.
  5. И опять несогласованность. Многие консольные программы поддерживают и -h и --help и даже показывают разные варианты справки.
    Но странно то, что git поддерживает -h не везде.
    git branch --help и git --help branch одинаково открывают git manual
    При этом git branch -h показывает короткую справку, а git -h branch — Unknown option: -h
Total votes 43: ↑43 and ↓0+43
Так вот и непонятно, отчего же гит не привели к более удобной системе команд? Ато пипец какой то.
Total votes 8: ↑8 and ↓0+8
Насколько я могу видеть, они постепенно приводят :). Тут ничего не сказали, к примеру, про «git push», который по умолчанию до версии 1.8 пушит все ветки и теги…

Мне кажется, люди любят гит больше за скорость и неприхотливость, нежели за его логичность в аргументах командной строки. Ну и сама история создания гита должна давать ответ на ваш вопрос: гит создавался как система управления патчами для kernel.org, и более-менее нормальный «пользовательский интерфейс» к нему начал появляться не так давно, и как раз он с каждой версией становится всё дружелюбнее.
Total votes 3: ↑3 and ↓0+3
Потому что так сложилось исторически. Когда-то читал интервью про Microsoft Office, там задавали вопрос «А почему у вас так много функционала и кнопок в ворде, нельзя ли убрать всё это нагромождение, мне нужно только форматирование и печать, например, 5% от всех возможностей».

Разработчики ответили, что так и есть, каждому нужно только 5%, проблема в том, что у всех они разные. Кому-то списки и абзаца, кому-то мастер слияния писем и без него никак. И стоит только что-то убрать, всегда найдутся недовольные:

image
Total votes 4: ↑4 and ↓0+4
Возможности программы, согласованность интерфейса и разделение ответственности между частями программы — это три разные вещи. Никто здесь не просит убрать функционал git, здесь просят изменить интерфейс. Народ из MS, к слову, не побоялся это сделать.

Конечно, внезапный переход на новую систему — не самая хорошая идея для git. Но взять и допилить тот же libgit2 (или написать что‐то своё, но обязательно с API — его отсутствие — это один из недостатков git), сделать на его основе новый CLI с учётом всех выявленных недостатков и объявить старый вариант deprecated (с поддержкой в течение нескольких лет) они вполне могут. Альтернативу — имея чёткий план по шагам ломать старый — тоже (правда, по‐моему, первый вариант легче пережить).

Если этого не сделать то легко повторить судьбу perl — желаемых изменений накопилось на целый новый язык, но популярность старого perl продолжает падать, а новый всё ещё не готов.
Total votes 2: ↑2 and ↓0+2
Осмелюсь дополнить.
3. Коммит хранит список своих родителей, их хеши. Никаких строковых ссылок на имена веток нет. Если подмержить ветку и удалить её, то о ней не останется никакого упоминания. В истории мы просто увидим разветвление на «тут были две какие-то ветки».
В коллективной разработке я предпочитаю некоторое время удерживать ссылки на ветки даже после полного мержа. Тогда можно хотя бы достать историю по ветке ($ git log master..feature-branch).
Ещё в git нет бранчей с «разрывами».
Total votes 3: ↑3 and ↓0+3
Ошибся. После слияния $ git log master..feature-branch работать не будет.
Пользуюсь $ git log --graph.
Total votes 1: ↑1 and ↓0+1
Потому что ветки — это не список коммитов, а указатель на головной коммит. Так что выяснить, в какой ветке внесено изменение просто невозможно после слияния. Ведь коммит будет входить во все ветки. И это правильно. Разве можно определить, какая ветвь сакуры выросла из какого корня :-)
Total votes 6: ↑4 and ↓2+2
UFO just landed and posted this here
В mercurial как раз честно: метка ветки это часть коммита.
Вообще git vs hg — это очень тонкий холивар, тоньше моего понимания.
Total votes 2: ↑2 and ↓0+2
Согласен, только вот в повседневной работе, hg (с его сокращенными командами, патчами mq) требует к себе больше внимания и времени, чем тот самый нелогичный гит.
Total votes 1: ↑1 and ↓0+1
Пользуюсь и тем, и другим, и это помимо обычных cvs-подобных систем контроля версий.

Гит не является дружелюбным, даже при использовании одним человеком, и не только потому что многие команды нелогичны. Проблема в том, что он требует слишком много моделировать в голове: вот у меня коммит, но я сейчас в ветке, и всё это еще локально, а на гитхабе еще пять коммитов новых появилось, и что в какой последовательности мне теперь делать? Садишься и чуть ли не рисуешь на бумажке первое время. При этом шанс потерять свои изменения совсем не иллюзорен, например предположу что все проходят stash + смена ветки, при этом untracked-файлы по умолчанию не включаются. И это система контроля версий, главное назначение которой хранить эти изменения!

Да, после пары месяцев, глубоких разбирательств вместо «да проще плюнуть и заново всё склонировать» и набивания всех шишек попутно с написанием самому себе памятки что-когда-в-каком-порядке можно начинать любить гит. Но не слишком ли это дорогая цена при наличии всё же более дружелюбного hg&mercurial?

Есть такой анекдот:
Русский сел на гвоздь, вскочил и давай матом ругаться. Украинец сел на гвоздь, вскочил, нащупал гвоздь, вытащил его и положил в карман: «В хозяйстве пригодится». Белорус сел на гвоздь, привстал и со словами «А может так и надо?» снова сел.

Иногда мне кажется, что давление от факта «ну все же им пользуются, может так и надо» всё-таки слишком велико.

p.s. Я понимаю, что параллельная разработка одного проекта кучей разных людей в любом случае сложная задача.
Total votes 7: ↑7 and ↓0+7
Я выразил субъективное мнение, которое может отличаться от вашего. Для меня гит проще в использовании и экономит время, нежели «мода» на этот продукт. Плюсы покажут кому что больше по душе)))
Total votes 2: ↑1 and ↓10
Несогласованность параметров различных команд. Одинаковые действия с различными сущностями не имеют ни чего общего.

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

деструктивные команды «специально» были сделаны так, чтобы в пылу кодинга таки нужно было включать мозг перед их выполнением?
Total votes 1: ↑1 and ↓0+1
Список всех — деструктивная команда?

Запутывание чего угодно — плохая идея.
Total votes 2: ↑2 and ↓0+2
UFO just landed and posted this here
В часть про хобгоблина еще стоило бы добавить наиочевиднейшую команту удаления remote бранча :)

git push origin :branchname
Total votes 15: ↑15 and ↓0+15
Начиная с Git 1.7, доступна команда git push origin --delete branchname. Хотя, мне уже привычнее старый вариант, да и печатать меньше.
Total votes 5: ↑5 and ↓0+5
И да, станет немного логичнее, если в вопросе этого двоеточия разобраться. Если писать команду полностью, то выйдет примерно так: git push origin localbranch:remotebranch. Соответственно, если локальную ветку не указывать, оставив разделитель-двоеточие, то указанная удаленная ветка удалится.
Total votes 5: ↑4 and ↓1+3
Ну я думаю это делает любой, кто задается вопросом «а с фига ли там вообще двоеточие?». Но тем не мене :)
Total votes 3: ↑3 and ↓0+3
Ок, то есть ветка с пустым именем — считается пустой веткой?

Тогда почему
git push origin :branchname
не падает по причине “Non-fast forward updates were rejected” и не требует ключа --force? Ведь изменения самые что ни на есть деструктивные, и уж точно не являются fast-forward.

По этой же логике удалить локальную ветку должно быть можно командой
git pull origin :localbranch
Total votes 5: ↑5 and ↓0+5
UFO just landed and posted this here
В последнее время от черепахи только отрицательные эмоции. Использую gitextensions вместо нее.
Total votes 3: ↑3 and ↓0+3
Нормальный SourceTree же вышел.
Total votes 2: ↑2 and ↓0+2
SmartGit/Hg, для некоммерческого использования бесплатно.
Total votes 1: ↑1 and ↓0+1
А я тысячу раз матерю — она жутко неудобная — столько много суетливых движений…
Только вод приходится это чудо использовать потому как почему-то консоли пугаются — юзеры, что с них взять
Total votes 1: ↑1 and ↓0+1
Интересно, кто-нибудь пользует http://hg-git.github.io/?
Для справки: плагин позволяет работать с git-репозиториями из mercurial.
Total votes 1: ↑1 and ↓0+1
А кстати, где-бы почитать умную статью-сравнение git и mercurial?
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
UFO just landed and posted this here
В могучем русском языке есть более однозначное слово «отдалённый», есть более однозначное (и краткое!) слово «стёртый».

Кто знает о них и продолжает употреблять «удалённый», тот виноват.

А язык винить нечего.
Total votes 4: ↑4 and ↓0+4
«Отдалённый» всё же обычно употребляется к обозримым объектам. Здесь объект не обозримый для человека, особенно без переключения контекста. Да и это уже давно устоявшийся термин, причём намного более употребительный (по отношению к своим синонимам), чем он же, но в значении «стёртый». Но вот если бы вместо «удалить удалённый репозиторий» было написано «стереть удалённый репозиторий» понять смысл было бы намного легче, уж к глаголу‐то в этом значении понятных и часто употребляемых синонимов более чем достаточно.
Total votes 2: ↑2 and ↓0+2
>Мастер Гит отправил последние новейшие изменения в master
>Master Git pulled down the latest changes on master

>отправил
>pulled down

Пойду-ка я лучше читать оригинал, а то перевод с подозрением на фактические ошибки слишком выносит мозг :)
Total votes 1: ↑1 and ↓0+1
«Как мне создать ветку?»
«Используй git checkout.»
git branch %branchname%
Total votes 4: ↑1 and ↓3-2
Обычно требуется не просто создать, но и сделать её текущей. В этом случае это будет этот самый git branch $branch, затем всё равно git checkout $branch. git branch нужен в основном только если вы случайно зафиксировали изменение не в той ветке, хотите переименовать ветку, разбить её на несколько или что‐нибудь в этом роде.
Total votes 2: ↑2 and ↓0+2
В повседневном использовании я тоже применяю «компактный вариант» checkout -b

Однако в тексте присутствует упрёк в том что комманда checkout предназначена для выполнения различных функций:
  1. переход на другую ветку
  2. создание новой ветки
В то время как:
  1. для перехода на другую ветку предназначена команда checkout
  2. для создания новой ветки предназначена команда branch
  3. для создания новой ветки и перехода на неё возможно использовать checkout -b
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
Какой вариант вы сочли бы логичным для «создания новой ветки и перехода на неё»?
  1. git branch --сheckout %branchname%
  2. git checkoutonewbranch %branchname%
  3. отсутствие одной команды и последовательное применение двух: branch и checkout
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
Именно поэтому -b это всего лишь флаг команды checkout. Странно упрекать команду за наличие удобной дополнительной опции.
Впрочем, Kain_Haart вам достаточно ясно объяснил ситуацию.
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
А почему не пэссив? Хвост машется собакой?
Total votes 1: ↑1 and ↓0+1
Удобной дополнительная опция (а лучше поведение по‐умолчанию с одним аргументом) была бы у branch. Если бы не было git и кучи упоминаний про именно этот флаг этой команды я никогда бы не додумался искать команду для создания и переключения на новую ветку именно там.

Именно в этом и состоит, насколько я понял, претензия develop7: когда вам нужна новая ветка вы хотите создать ветку и переключиться на неё, но git предлагает только переключиться на ветку, попутно её создав. Ни до, ни после знакомства с git я не думаю об этом действии иначе, чем «создать и переключиться». А ветки создаются git branch. Основное действие — «создать», не «перейти». Kain_Haart не объяснил ничего, кроме того, что мы и так знали.
Total votes 3: ↑3 and ↓0+3
Sign up to leave a comment.

Articles

Show the best of all time
Unlock dark mode

Your account

Sections

Information

Services

Support
© 2006–2024, Habr