По работе приходится участвовать в разных проектах, поэтому я хорошо знаю, как работают все мои коллеги. Помню, что компания начала использовать Git буквально за пару недель до моего прихода. На мониторах разработчиков кругом висели наклейки с напоминанием: сначала add, потом коммит, затем пуш.
Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.
Мне нравится составлять карту в голове. Я не говорю «ментальные карты», потому что это хорошо известный тип диаграмм. Речь о неких картинках, структурах или любом графическом представлении в уме. Например, в детстве я учила арифметику, представляя игральные кубики.
Поэтому я подготовила несколько рисунков. Не обязательно их смотреть, чтобы понять текст. Для каждого есть пояснение.
Кроме того, очень важно научить человека терминам. Иначе он не поймёт сообщения от Git. Рисунки — хороший способ.
На рисунке четыре области распределены следующим образом:
Здесь можно объяснить преимущества распределённой системы управления версиями.
При клонировании данные из удалённого репозитория перемещаются в две области:
В рабочем каталоге два типа файлов:
После подготовки изменений в рабочем каталоге их необходимо добавить в промежуточную область (staging area).
Когда там накопился ряд изменений с общей целью, самое время создать в локальном репозитории коммит с сообщением об этой цели.
Если в локальном репозитории есть один или несколько коммитов, готовых к совместному использованию всем остальным миром, они отправляются в удалённый репозиторий.
В этот момент можно говорить о различных состояниях файла в среде разработки: изменённом, промежуточном (staged) и зафиксированном (commited).
Далее вы можете объяснить:
При выполнении
При выполнении
Если важна история коммитов, рассмотрите возможность использования
Можете добавить в среду разработки ещё одну область, чтобы проще прятать накопленные изменения: грязный рабочий каталог.
Когда люди усвоят эти понятия, вам будет легче объяснить дальнейшее: ветви, историю коммитов, перебазировку и так далее, потому что прочный фундамент уже заложен.
Я работала с другими системами управления версиями (Visual SourceSafe, TFS и Subversion): по моему скромному опыту, недостаток знаний вредит и со старым инструментом, и с новым. Сосредоточьтесь не только на выборе инструмента, но и на его освоении.
Мой друг Марк Виллаграса напомнил, что очень полезно решить задачки Git и делиться с коллегами решением.
Ресурсы из комментариев на Hacker News:
Прочитав комментарии на Reddit, я подумала, что более точным названием этой статьи было бы «Идея, как научить людей использовать Git», потому что это только идея, которая появилась в моей голове, когда я сама несколько лет назад изучала Git по книге Pro Git. Статья не является полным руководством, лишь отправная точка. Уверена, что все эти ресурсы будут очень полезны. Спасибо!
И спасибо Стюарту Максвеллу, который поделился ссылкой на Hacker News, и u/cryptoz, который запостил её на Reddit!
Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.
Идея
Мне нравится составлять карту в голове. Я не говорю «ментальные карты», потому что это хорошо известный тип диаграмм. Речь о неких картинках, структурах или любом графическом представлении в уме. Например, в детстве я учила арифметику, представляя игральные кубики.
Поэтому я подготовила несколько рисунков. Не обязательно их смотреть, чтобы понять текст. Для каждого есть пояснение.
Кроме того, очень важно научить человека терминам. Иначе он не поймёт сообщения от Git. Рисунки — хороший способ.
Распределенная система контроля версий
На рисунке четыре области распределены следующим образом:
- Среда разработки:
- Рабочий каталог
- Промежуточная область (staging) или индекс
- Локальный репозиторий
- Сервер:
- Удалённый репозиторий
Здесь можно объяснить преимущества распределённой системы управления версиями.
Клонирование репозитория
При клонировании данные из удалённого репозитория перемещаются в две области:
- Рабочий каталог
- Локальный репозиторий
Внесение изменений в рабочий каталог
В рабочем каталоге два типа файлов:
- Отслеживаемые: файлы, о которых знает Git.
- Неотслеживаемые: которые ещё не были добавлены, поэтому Git не знает о них.
Обновление удаленного репозитория
После подготовки изменений в рабочем каталоге их необходимо добавить в промежуточную область (staging area).
Когда там накопился ряд изменений с общей целью, самое время создать в локальном репозитории коммит с сообщением об этой цели.
Если в локальном репозитории есть один или несколько коммитов, готовых к совместному использованию всем остальным миром, они отправляются в удалённый репозиторий.
В этот момент можно говорить о различных состояниях файла в среде разработки: изменённом, промежуточном (staged) и зафиксированном (commited).
Далее вы можете объяснить:
- как показать изменения файла в рабочем каталоге:
git diff - как показать изменения файла в промежуточной области:
git diff --staged - как изменить файл в рабочем каталоге после добавления в промежуточную область
- и т. д.
Обновление среды разработки
Получение (fetching)
При выполнении
git fetch данные из удалённого репозитория перемещаются только в локальный репозиторий.Вытягивание (pulling)
При выполнении
git pull данные из удалённого репозитория перемещаются в две области:- В локальный репозиторий:
fetch - В рабочий каталог:
merge
Если важна история коммитов, рассмотрите возможность использования
git pull --rebase. Тогда вместо команд fetch + merge выполняются команды fetch + rebase. Ваши локальные коммиты будут воспроизведены, так что вы не увидите в истории коммитов известную форму бриллианта.Дальнейшие действия
Можете добавить в среду разработки ещё одну область, чтобы проще прятать накопленные изменения: грязный рабочий каталог.
Когда люди усвоят эти понятия, вам будет легче объяснить дальнейшее: ветви, историю коммитов, перебазировку и так далее, потому что прочный фундамент уже заложен.
Дружеское напоминание
Я работала с другими системами управления версиями (Visual SourceSafe, TFS и Subversion): по моему скромному опыту, недостаток знаний вредит и со старым инструментом, и с новым. Сосредоточьтесь не только на выборе инструмента, но и на его освоении.
Дальнейшее чтение
Полученные отзывы
Мой друг Марк Виллаграса напомнил, что очень полезно решить задачки Git и делиться с коллегами решением.
Ресурсы из комментариев на Hacker News:
- Величайшее изобретение Линуса Торвальдса
- Лекция Линуса Торвальдса о Git
- Linux.conf.au 2013 — Git для детей от 4 лет
- Git от начала до конца
- Git от начала до конца (PDF)
- Изучаем ветвления Git
- Правила полётов для git
- Пакет Emacs: Magit
- Как написать хорошее сообщение для коммита
- Станьте гуру git
- Погружение в Git
- Udacity: как использовать Git и GitHub
Прочитав комментарии на Reddit, я подумала, что более точным названием этой статьи было бы «Идея, как научить людей использовать Git», потому что это только идея, которая появилась в моей голове, когда я сама несколько лет назад изучала Git по книге Pro Git. Статья не является полным руководством, лишь отправная точка. Уверена, что все эти ресурсы будут очень полезны. Спасибо!
И спасибо Стюарту Максвеллу, который поделился ссылкой на Hacker News, и u/cryptoz, который запостил её на Reddit!
Vass
Если в 2019 году разрабочик не умеет в Git, то такой разработчик не нужен.
ponich
Перестаньте. Управляю кодом с помощью git'а уже больше 6 лет, но поверьте, я не знаю этот инструмент. Что говорить уже о юных падаванах?
KvanTTT
Как вы им управляете и не знаете?
khim
Я думаю имелось в виду, что всех тонкостей не знает…
ponich
Именно. Спасибо.
Я ежедневно пользуюсь rebase/marge, show/log/diff, stash, reset/checkout, cherry-pick и мне этого хватает. Но признаюсь честно, я очень часто иду спрашивать в гугла или у своих коллег по цеху.
Git имеет больше десятка полезных утилит, с своими параметрами и опциями. Я бы очень сильно хотел знать их все, а еще лучше правильно это все применять.
А программист который пришел в команду без базовых знаний, получить их в первую неделю работы. И такого человека нужно брать. Ибо если не вы то другие
KvanTTT
Этого более чем достаточно, Git вы наверняка знаете. Не обязательно на 100% знать возможности инструмента чтобы эффективно его использовать.
Keyten
За ~6 лет ни разу не понадобился rebase. Обычно только clone / add / commit / push / pull / status. Около 2 лет назад начал юзать merge, checkout, log и stash (да-да, я не юзал ветки). Раза 3 за всё время использовал cherry-pick. Иногда юзаю reset по подсказке гита. сам её синтаксис не помню.
khim
А что вы используете если вашу фичу месяц не хотят принимать, если не rebase???
Keyten
Ээ… мердж и фикс конфликтов руками?
khim
Ну можно и так, наверное, но потом непонятно как это ревьюить.
Я как-то привык к тому, что мёрдж допустим только тогда, когда конфликтов нет…
Endeavour
git merge X# there are conflicts
git mergetool
# N часов разрешения конфликтов спустя
git commit
khim
Последующие пункты:
# оно посыпалось в проде (так как конфликты как-то разрешили, но тестировать не тестировали)
# научились пользоваться rebase
Endeavour
А что, ребейз автоматически исправляет ошибки?
После мержа мастера в фичу, разрешения конфликтов, фича пушится, CI прогоняет тесты, и мержится мерж реквест.
khim
А что, ребейз автоматически исправляет ошибки?После ребейза следует ещё одна стадия: проверка всего, что случилось и исправление ошибок.
После мержа мастера в фичу, разрешения конфликтов, фича пушится, CI прогоняет тесты, и мержится мерж реквест.Однако при этом разработчик, почти никогда, не смотрит на то, что там произошло и почему возник конфликт. Потому что у вас на всё стадию разрешения конфликтов — один шаг:
# N часов разрешения конфликтов спустя
В случае же с rebase вы вполне можете решить сделать его в несколько шагов. Или вообще интерактивно — с проверкой после каждой стдии. Контроля над процессом — на два порядка больше.git commit
poxvuibr
Или эта стадия следует за мёржем мастера в фичу, который обязательно надо сделать перед тем, как делать пул реквест.
Yeah
Endeavour
В гитлабе такие графы выглядят гораздо читаемее.
KvanTTT
Или в GitExtensions, например
nothern_wind
осторожно, двери закрываются следующая станция ff9af9b0fb70e75839761489c5b1880d77adf90d
Ох уж эти схемы линий git'овского метрополитена;)
n00ker
вы серьезно? за что вы так не любите ревьюверов? =)
а если в вашей feature бранче из множества коммитов нужно поправить 3-й с конца — как вы делаете?
Endeavour
Правишь и коммитишь. Править коммит в глубине истории — очень странное использование гита.
khim
Интесная точка зрения, если учесть что это «странное использование» — это то, ради чего, собственно, git и был создан изначально.
Endeavour
Гит намеренно делает очень сложным переписывание истории.
Отличный пример — git revert: создает новый коммит, откатывающий более ранний, вместо внесения изменений в историю.
khim
Git намеренно делает сложным незаметное переписывание истории, да. История, которая уже опубликована — изменению не подлежит.
А вот для изменения истории, которая ещё не опубликована — как раз rebase и предназначен. А до него пользовали Quilt, да.
mayorovp
При чём тут revert? svn revert тоже как бы создает новую ревизию. Revert никогда не предназначался для исправления истории.
А для исправления коммитов в прошлом есть довольно удобный инструмент: комбинация
git commit --fixupиgit rebase --interactive --autosquashn00ker
а вы точно знакомы с git-flow? =)
OnYourLips
С каких пор это сильно сомнительное флоу стало непреклонной истиной?
И почему это вы вспомнили про него в ответе на комментарий?
n00ker
сильно сомнительное флоу? =) ок, а какое флоу вы считаете не сомнительным?
почему вспомнил — ну, так кейс такой. вот сделали вы локальную feature бранчу. в ней куча атомарных коммитов. и нужно поправить третий коммит с конца.
вопрос — как это сделать без rebase?
основная идея в том, что rebase очень полезная команда =)
OnYourLips
А еще можно автоматически засквошить всю фичу в один коммит.
Но при чём тут гитфлоу?
Гитлабовское, например.
n00ker
вы тоже не любите ревьюверов? =)
khim
А для этого требуется следующее:
1. Все коммиты обозримы и, как правило, имеют небольшие размеры (иначе смысл делать git bisect: найдёте вы коммит размером в миллион строк, меняющий несколько тысяч файлов… что дальше?).
2. Каждый коммит имеет смысл в отдельности, сам по себе (иначе, найдя него, нельзя понять что в нём пыталось сделать и зачем).
3. Каждый коммит содержит в себе образ, который можно собрать и не содержит ошибок (тут стоит, конечно, уточнить: «насколько нам известно можно собрать» и «известных ошибок, которые мы не решили сознательно не править „здесь и сейчас“»). Самое важное и, вместе с тем, самое спорное свойство — но если оно не соблюдается, то всё время будете через git bisect находить не что-то полезное, а тот мусор, который вы оставили во время разработки.
Ключевая фича Git'а — это git bisect. Он позволяет искать ошибки в крупных проектах, над которыми работают тысячи разработчиков. Однако накладывает ограничение на то, что вы кладёте в ваш репозиторий.
Но, разумеется, если ваш проект невелик, то это не особо нужно. А если вы один работаете — то и папочек с датами может быть достаточно.
poxvuibr
rebase многократно увеличивает трудозатраты, которые нужно сделать для git bisect.
develop7
аналог changeset obsolescence из Mercurial сильно помог бы, но в Git ничего подобного нет и в обозримом будущем не появится
khim
Каким образом?
poxvuibr
После того, как сделан rebase каждый коммит потенциально может быть сломан из-за того, что изменения в мастере оказались несовместимы с тем, что осталось в ветке. Например, в мастере был переименован какой-то метод. Конфликтов не возникнет, но код перестанет собираться.
Автоматический bisect в таком случае естественно скажет, что коммит сломан. Чтобы такого не было, после rebase нужно прогнать тесты на каждом коммите и потенциально поправить код в каждом коммите.
Lissov
Чтобы такого не было, надо после каждого rebase проверить сво код так, как будто написал его на основе нового кода.
khim
Мне казалось, что это само собой разумеется. Если вы делаете rebase — то вы делаете его для того, чтобы облегчить себе задачу в будущем, а не наоборот. Если у вас нет времени на то, чтобы прогнать тесты, то rebase делать не стоит, вот и всё.
poxvuibr
Ну вот если хочется использовать bisect, то rebase очень осложняет задачу.
Ну в общем да. Допустим в ветке работали около недели, там 100 коммитов. Тесты прогоняются, допустим, около двух минут. Для каждого коммита нужно прогнать эти тесты. Итого, примерно три с половиной часа нужно потратить на просто прогон тестов, плюс, думаю, не менее минуты на коммит для сопуствующих действий. Так что да, если жалко четырёх с половиной часов — не стоит делать rebase.
Lissov
В таком случае я бы вообще не стал делать rebase уже не задумываясь ни о чём другом.
poxvuibr
Ну да, а ветки в с какой-нибудь фичей, они в основном такие и есть.
Lissov
Смотря что в Вашем понимании «фича». У нас это уровень функционала на несколько месяцев работы — такое часто лучше делать частями на мастере. Ну или merge без вариантов. А задачи от дня до недели, баги на пару часов — там один или два коммита будут.
TheShock
Lissov
Такие вещи не всегда возможно, но часто очень удобно делать с помощью feature toggle. Но вообще мы уходим от основного вопроса. Такие фичи, конечно же, надо мержить через merge по целому ряду причин.
khim
А почему неуозможны-то? Что может мешать? Просто Chrome всё свои фичи так делает — и как-то ни во что особо не упирается.
Это если сомнений в том, что фича нужна нет.
Если есть. То всё равно: если уж так приспичило их тоже нужно переносить если не на самую голову, то хотя бы близко к ней. Да, это время и силы, но если вы уже вложили в фичу месяц работы, то потратить ещё день, чтобы причесать её перед заливкой — не слишком долго.
Хотя, конечно, тут приходится мириться с тем, что фича будет не поверх прямо последней версии, а поверх версии трёхдневный давности… что всё равно лучше, чем если она поверх версии годичной давности и «merge commit» переписывает половину кода…
TheShock
Иногда в коде не может быть следов новой фичи до окончательного релиза, чтобы игроки не получили спойлер до того, как отдел маркетинга начнет свою работу.
Endeavour
100 наверно перебор, но 50 вполне.
khim
Но… Зачем? Что вы такого делаете, что нельзя разбить на несколько подфич и вливать по 5-7 коммитов?
Да, пару раз в год у меня случатся хитрые фичи, которые нельзя разбить на 10 мини-фич… ну так пару раз в год можно и подождать 4 часа.
А так — чем меньше фича, тем лучше для ревьюера.
TheShock
А какие проблемы с мерджем, если месяц не мерджить и если были конфликты? На Гитхабе в Пул Реквестах все норм.
khim
Так за этот месяц туда будут влиты несколько тысяч коммитов и половина интерфейсов, которые вы используете, поменяется.
То есть по объёму ваш «финальный» мёрдж будет как половина от 10-20-50 компотов, вашу фичу реализующих. Ну и как это ревьюить, извините?
TheShock
khim
Отлично. Я, ревьюер, cмотрю на первый коммит, вижу, что там используется функция Foo, которой больше нет в мастере, прошу её заменить на более новую Bar (которая есть в мастере, но которой нет в той версии, в которой вы начали разрабатывать вашу фичу).
Ваши дальнейшие действия?
TheShock
Мердж из мастера в фиче-ветку, замена Фоо на Бар, проверка, коммит, пуш.
На гитхабе автоматически обновился пул-реквест.
mayorovp
Вы не поняли. Мердж вы уже сделали, но ревьювер смотрит старый коммит…
TheShock
Зачем?
khim
Чтобы понять что он делает, очевидно. А про функцию Foo я давно забыл и желания вспоминать про то, как она работала у меня нет никакого.
В конце-концов вы же попросили, чтобы я включил вашу фичу в новую версию — так нафига мне знать что и как вы делали у себя дома, когда эту фичу разрабатывали?
Мне интересно знать как она будет работать в моей подсистеме сегодня. Ревьюер в ядре — как правило майнтейнер соответствующей подсистемы и это ему (или ей) этот под поддерживать если вы вдруг исчезните (да даже если и нет).
TheShock
Вы пользовались когда-нибудь пул-реквестами на Гитхабе? Я понимаю, что с велосипеда можно снять сидушку и жаловаться, что неудобно, но зачем?
mayorovp
А вы пользовались? Если пользовались, то должны знать, что там именно что отдельные коммиты на ревью попадают. Поэтому перед тем как делать PR очень желательно сделать rebase.
TheShock
Там, конечно, есть список коммитов, которые вошли, но основная часть — это изменения, разница между «до» и «после». Ни один адекватный ревьюер не будет заходить в первый коммит и его ревьюить без контекста остальных без необходимости
mayorovp
А как ему этот самый контекст получить, когда в последнем коммите — краткая подборка всех изменений из основной ветки проекта за последний месяц?
Почему вы не желаете немного помочь ему и убрать из своего PR мусорную информацию?
TheShock
khim
И да, каждый из них должен иметь смысл, не должен быть слишком большим (если он больше 100 строк, то его могут попросить разбить) и так далее.
В ядре есть ещё сложность что разные люди пользуются разными инструментами, так что можете посмотреть примерно как это Chromium делает. Там инструмент у всех один…
Инструменты у разработчиков ядра, Chrimium, Android, LLVM — всё разные. Но принцип один: каждый коммит ревьюится отдельно. И должен иметь смысл — отдельно.
А иначе что делать после Git Bisect.
TheShock
khim
Никак разумеется. Какой же идиот большую фичу склеивает в один коммит? Наоборот: скорее её нужно будет интерактивным ребейзом дополнительно на части делать — чтобы ревью было удобнее делать.
mayorovp
Это не ребейз такие коммиты порождает, а мерж. Когда вы делаете слияние мастера в вашу фиче-ветку, вы порождаете коммит, который, с точки зрения вашей ветки, выглядит как месячная история слепленная вместе.
И она-то и мешает ревью.
khim
Мешает ревью не этот коммит, а просто тот факт, что rebase не сделан.
Ведь, собственно, почему все эти замены Foo на Bar появляются? Чтобы помочь вам вашу фичу реализовать.
То есть, к примеру: если вы хотите сериализовать какой-то объект, но есть шанс, что этот объект «под вами» менять будут — его можно попробовать изменить так, чтобы он был immutable. И проблемы синхронизации исчезнут. Но для этого — его нужно будет создавать по-другому.
А когда вы, после всего этого выкатываете на ревью версию «с костылями»… Ну это просто неуважение к ревьюерам, которые для вас, собственно, всю эту работу и проделали.
Рассказывать после такого «плевка в лицо» о «работе в команде»… Ну как-то глупо это…
khim
Он не просто туда «зайдёт». Он его рассмотрит, напишет замечания и на этом, скорее всего успокоится. Ибо какой смысл ревьюить последующие коммиты, если неизвестно как будут исправлены проблемы, отмеченные в первом?
TheShock
Зачем, если можно ревьюить результат пул-реквеста?
khim
Кто мне разобьёт «результат пул-руквеста» на отдельные маленькие кусочки? И что мне делать с компотами, на которые я никогда не смотрел, если на них git biset укажет?
khim
Причём тут пулл-реквесты на гитхабе? Я, как ревьюер, отвечаю за каждый отдельный коммит. Ибо на нём мой signoff стоять будет.
И если меня коммит не устраивает — я signoff не поставлю. Вот так вот просто.
Github вообще энфорсит совсем другую модель. Leftpad-стайл, условно говоря: я беру у вас фичу и не глядя забираю себе. Кто и как при этом будет чинить отвалившуюся другую фичу — науке неведомо.
Такое в массе крупных проектов просто «не прокатывает»: если я даю «добро» на включение чего-то в проект — то это я должен быть готов править ошибку, совершённых в любом из показанных мне коммитов, если git bisect на этот коммит укажет.
Как GitHub pull-реквесты помогут мне в этом — я не понимаю.
TheShock
Ну я понял. «будет или по моему или никак». Удачи в работе в команде.
khim
Это вам удача понадобится, если вы вдруг в большой проект (ну, скажем, от 10 миллионов строк и больше) что-то закоммитить решите. Я вот не знаю ни одного, где бы играли по вашим правилам.
mayorovp
Вот не надо про "не глядя". Там есть все средства для проведения ревью, а дальше уже дело за мейнтейнерами проектов будут ли они эти средства использовать.
Между прочим, github автоматически подписывает все сделанные через веб-интерфейс коммиты.
khim
От того, что GitHub, от моего имени, подпишет коммиты, которых я в глаза не видел — мне только хуже.
mayorovp
А зачем вы нажимали кнопку Merge не глядя на коммиты? И почему виноват гитхаб?
Так-то можно и самостоятельно коммит слияния подготовить и запушить, если вам так важно чтобы подпись была именно ваша.
khim
Остаётся только «не глядя» вливать… И надеяться, что код, который получился — правильно работает…
mayorovp
При чём тут «без rebase»? В этой ветке я оспариваю ваше утверждение, что «Github вообще энфорсит совсем другую модель. Leftpad-стайл».
lorc
все так, только не signed-off, a acked-by или reviewed-by
khim
Извиняюсь, да.
khim
MacIn
Как насчет workflow, где фича всегда разрабатывается на основе актуальной dev(trunc) ветки? И ревью производится готового кода в составе полного, компилируемого кода в этой ветке.
mayorovp
А что делать если одновременно разрабатываются две фичи?
MacIn
Вы имеете в виду, что во время разработки одной пришлось вотпрямсрочно перейти на разработку второй? Сохранить изменения — stash или как там это называется в git'е (положить на полку), потом вернуться.
В целом, это показатель неоптимального рабочего процесса, кмк.
mayorovp
Я имею в виду, что на проекте более одного разработчика, и у каждого — своя задача.
MacIn
Простите, но тогда мне не совсем ясен изначальный вопрос: «что делать если одновременно разрабатываются две фичи» — разрабатывать одновременно две фичи. Понятно, что проблема появляется только если области разработки пересекаются, но это решается дроблением задач и частыми коммитами для синхронизации. Синхронизация один-два раза в день вполне достаточна, чтобы не иметь проблем вида «они так все поменяли, что нам надо все переделать».
Kobalt_x
то ревьюер смотрит их независимо, если всплывает конфликты инвайтит другого разработчика observerом, если нужна интеграция делается интеграционная ветка где есть обе фичи, на ней гоняются тесты и она мерджится в мастер
Valle
Лучше бы вам merge никогда не надобился, а то очень сложно разобраться в графе истории разработки, где 80% это всякие мержи.
develop7
Вопрос представления. В IDEA, к примеру, merge commits отрисовываются приглушёнными цветами, а при желании их можно вообще спрятать.
0xd34df00d
А зачем в графе разбираться?
Я гитом пользуюсь лет 10, и ни разу не приходилось именно разбираться в графе. Грепать логи приходилось, бисектить приходилось, git blame делать приходилось, а вот на граф смотреть — нет.
samodum
Именно так
ponich
del
kzhyg
xkcd.com/1597
n00ker
имелось в виду, если разработчик не знает git на уровне ваших картинок, то такой разработчик не нужен. а вы подменяете «знает на уровне, чтобы работать в команде» на «знает на 100%». ну так спешу вас огорчить, вы ничегошеньки не знаете на 100%. вообще удивлен, что ваш комментарий огрёб столько плюсов.
ponich
У меня в команде есть ребята, которые без декстопных приложений не смогут отправить свой коммит. Некоторые о git узнали в процессе написания диплома, только потому что нужно было что-то туда писать. Это не делает их плохими разработчиками.
Извините, но плюсы меня не интересуют. Даже если бы заминусовали, я бы не отказался от своих слов.
OYTIS
Это делает их неопытными разработчиками. Что совершенно нормально для человека, который только написал диплом. Другое дело, если культура предприятия это поддерживает, тогда развитие у ваших сотрудников будет идти не так хорошо, как могло бы.
В принципе, никакой ракетной техники в git нет — я сам работал на предприятии, где использовался (и, наверное, до сих пор используется) SVN, и переучиться на git стоило, конечно, некоторых усилий, но не то, чтобы запредельных. Но такие мелочи могут накапливаться, и делать предприятие (и, соответственно, строчку в резюме ваших сотрудников) «uncool».
helg1978
можно уметь mercurial, например
pfemidi
Занимаюсь программированием с 1988-го года, то есть 30 с лишним лет, с интересом читаю статьи с описанием всяких хитростей Git, думаю «Надо всё же когда-нибудь попробовать! Раз уж от этого Git все так тащатся!», но… Некогда мне Git изучать, работать надо, поэтому пробы всё откладываю и откладываю из раза в раз. Позор мне. Пойду убьюсь об стену.
staticlab
А вы в принципе пользуетесь какой-либо системой контроля версий? Например, CVS или SVN? Если нет, то как вы работаете в команде? Или вы 30 лет с лишним лет программист-одиночка?
sborisov
У меня тут на новой работе дали проект из загадчика, парни, он в source safe ещё локальном хранится, вот где Содом.
Я его через vss2git сконвертировал в git, чтобы историю хотя бы в нормальном виде смотреть...
pfemidi
Было время я пользовался Microsoft Visual SourceSafe, год, с 2000-го по 2001-й год когда работал в команде, там это был корпоративный стандарт. Но там было просто, мне показали что надо нажимать в начале рабочего дня чтобы скачалась последняя версия проекта и что нажимать в конце рабочего дня чтобы другие увидели что я там за день наделал, это я и нажимал. А ни до этого, ни после этого никакими системами контроля версий я никогда не пользовался, непонятны они мне, а посему неудобны. Сейчас меня закидают тухлыми яйцами, но мне удобно по-старинке: добился работоспособности — «закоммитил» директорию с проектом у себя в ProjectName.dd-mm-yyyy и продолжил делать в ProjectName. Не получается — сделал «checkout» путём переноса из ProjectName.dd-mm-yyyy обратно в ProjectName. Получилось — «закоммитил» директорию с проектом в следующую директорию опять с указанием даты ProjectName.dd-mm-yyyy. И время от времени бекаплю всё это дело на внешний диск, удаляя у себя на локале наиболее старые ProjectName.dd-mm-yyyy, но оставляя на внешнем диске все. И нет никакой головной боли что там лучше делать merge или rebase, и не надо придумывать никакие commit messages, и не надо синхронизировать никакие ветки. А историю изменений по ходу изменений записываю (с указанием что менял и даты) в обычный текстовый файл Changelog.txt в корне проекта. По этому Changelog.txt в случае чего необходимую директорию ProjectName.dd-mm-yyyy найти не просто, а очень просто и без всяких bisect. И да, в команде я с 2001-го года больше не работаю, работаю один. Из git я освоил только clone чтобы иногда скачивать что-нибудь с гитхаба. В принципе init, add, checkout, и commit я могу в Git использовать, но зачем? Если моё версионирование через директории ProjectName.dd-mm-yyyy делает в принципе то же самое, только [для меня] гораздо более прозрачно и устраивает меня на 100%. А вот про всякие cherry-pick, revert, tag, submodule и прочие, а ещё какие-то жуткие, нечеловеческие, сделанные явно для того чтобы в конец запутать способы указания номера коммита через немыслимые HEAD, HEAD~1, HEAD^ и т.д. — я только знаю что такое есть, но что это, зачем это нужно и как этим пользоваться понятия не имею и побаиваюсь. И некогда мне это изучать. Вот как-то так.
Сказал как есть и поэтому к приёму очереди из тухлых яиц готов.
humbug
Я правильно понимаю, что вы работаете над проектами один?
staticlab
humbug
Оттого ваш стиль с версионированием директории ProjectName.dd-mm-yyyy вам подходит. Если бы в команде был хотя бы +1, то вы бы уже давно сознательно переползли на систему контроля версий.
KvanTTT
Git (либо другую систему контроля версий) можно и удобно использовать даже если разработчик один.
sborisov
У нас был случай в 2001м ~ 2002м, писали софт для такси (на Дельфи ещё), используя ProjectName.dd-mm-yyyy на локальной машине.
И вот в один прекрасный день, админ решил обновить на этом компе драйверы для видеокарты nvidia, забыв создать точку восстановления перед установкой…
Но что-то пошло не так, решил откатится — и откатился на точку восстановления, сделанную 2 недели назад…
Уже на следующий день у нас был отдельный сервер с svn.
Вот так незатейливо и началось знакомство нашей компании с системами управления версиями!
springimport
Никогда не пользовался восстановлением, что на винде, что в линуксе. Потому что это черный ящик который вообще не понятно как работает, в нем легко ошибиться (ваш случай).
По моему, это где-то возле частого форматирования дисков вместе с критически важными дисками каждый день без бэкапов с вероятностью 1% форматнуть не тот диск.
SandroSmith
Простите, а проекты лежали в %windir%? Ибо емнип, точки восстановления не затрагивают пользовательские файлы. Или мне нужно очки снять?
mayorovp
Обещают-то что не затрагивают, а вот реально я тоже файлы терял. Нет, лежали не в %windir%, а просто в c:\Projects
humbug
Кто ж спорит?)
KvanTTT
Непонятны и неудобны потому что видимо не пользовались нормально.
Какой кошмар! Действительно закидают.
Использую Git, голова давно не болит. Все эти вещи только лучше все организуют и систематизируют.
Прозрачности тут гораздо меньше — куча лишнего и дублирующегося, отсутствие истории, дифа файлов.
Использовать эти команды вовсе не обязательно, разбирающимся они только помогают. Что нечеловечного в хеше коммита, тэгах, дате?
mapron
Хеш коммита поначалу действительно страшная вещь, если ты до этого только папочки копировал)
Для pfemidi предложение у меня такое:
начать использовать Git, создать в директории с вашим проектом рабочую копию через git init, закоммитить все текущие файлы с коммитом «initial»
Затем при внесении изменений, вместо создания копии папочки с
ProjectName.dd-mm-yyyy
вы просто делаете git commit с текстом «ProjectName.dd-mm-yyyy».
(меня сейчас закидают тухлыми яйцами уже поклонники Git)
т.е. в вашем привычном способе разработки не изменится, но вы сможете использовать некоторые плюшки, как только захотите.
Например, посмотреть diff между версиями ;)
ну а потом уже и нормальные имена коммитов, и ветки, и все остальное само подтянется. Сабмодули, cherry-pick, для индивидуальной разработки вам вряд ли понадобятся, tag — ну многие проекты их не используют, кстати говоря, revert — если не косячить с коммитами, то и откатывать не надо.
В общем я считаю, начинать осваивать гит с одной единственной команды -реально ;)
Skerrigan
Никак не истина, лишь частный случай, но я «один разработчик» и да, я весьма активно использую cherry-pick. Просто софт стал весьма сложным. Некторые подсистемы могут писаться как «экспериментальные» в отдельной ветке. Что-то может быть в разработке и по 3 месяца. А потом принимается решение, что это надо «в основной системе».
Приучило не писать монолиты… минимальная связанность — благо «при сборке из кубиков» есть всегда @Override-аннотация и в модулях дает писать «заглушки».
iago
Я тоже как-то 1.5 года был одним разработчиком, и даже бранчами пользовался, хоть и редко. Без гита, хотя бы блэйма и истории, не представляю как вообще код писать. Как домой вечером уходить-то? А если проект занимает сотни мегабайт (либ много, а в современной iOS разработке они все большие, т.к. все статически линкуется) то как без гита, все сотни мегабайт архивировать?
Skerrigan
Я не возражаю, только дополняю: бывает что несколько дней веду работу «офис-дом» с использованием «удаленного рабочего стола». Пинг хороший.
Такое в ряде ситуаций бывает удобным.
sumanai
А для этих либ разве нет никакого пакетного менеджера? На PHP достаточно сохранить package.json и composer.lock, на ноде package.json и package-lock.json. Ни разу не было даже мысли архивировать или коммитить зависимости.
KoToSveen
Стоит начать с малого. Просто коммиты, создание/слияние веток.
станут выглядеть для Вас, как ССЗБ.Уверяю, все эти
Попробуйте Git Extensions (Win).
Usul
Раньше я работал так же, как и вы — архивы по датам, changelog и т.д. А потом стал использовать mercurial, и жизнь значительно упростилась. Более того, мне до сих пор приходится работать с некоторыми системами по-старинке, через архивы (всякие там STEP7 и тому подобное, где код хранится в файлах бинарного формата). По сравнению с нормальными системами контроля версий, это просто адъ. Поэтому скажу пару слов в защиту СКВ. Не имею намерений что-либо навязывать и, тем более, кидать в вас тухлые яйца. Расценивайте мое сообщение как ИМХО.
Ваш стиль работы можно очень легко перенести на git или hg, и вы это, похоже, прекрасно понимаете, но не видите преимуществ. В чем профит? В том, что система контроля версий возьмет на себя прорву чисто механической работы. Например, сейчас вы делаете изменения в проекте, потом пишете в changelog «22.01.19 Реализовал фичу XYZ. Изменил aaa.cpp, bbb.cpp, ccc.cpp». А с любой СКВ и GUI-клиентом к ней вы просто набираете в окне сообщение «Реализовал фичу XYZ» и жмете Commit. Все. GUI-клиент типа TortoiseHG или Sourcetree четко показывает вам, что изменилось. Выделили коммит в списке — видите, что этот коммит изменил файлы aaa.cpp, bbb.cpp, ccc.cpp. Выделили файл aaa.cpp — сразу видите, что конкретно поменяли. То есть система ведет максимально подробный «changelog» за вас. Ориентироваться во всем этом вы сможете очень просто, причем безо всяких хитрых команд. Вам не нужен bisect, чтобы читать список изменений.
Хотите вернуться к предыдущему состоянию? Выделили коммит и сделали на нем «Update». Нужен бэкап на внешнем винте? Один раз сделали на этом винте клон вашего репозитория а потом периодически делайте туда push. Более того, с git и mercurial вы сможете завести бесплатные аккаунты на сервисах типа github, gitlab, bitbucket и бэкапить туда.
Какие еще преимущества? Навскидку, для любого файла в проекте можно посмотреть историю изменений. В большом проекте иногда натыкаешься на какой-то хитрый участок кода и начинаешь вспоминать: когда это делали и зачем. В GUI-клиенте можно парой кликов мыши вывести историю файла, вплоть до текста файла с построчной аннотацией — когда (и кем) менялась каждая строка.
Размеры репа, если не коммитить туда бинарники, очень скромные, по сравнению с сохранением полного архива ProjectName.dd-mm-yyyy на каждый коммит. Всегда можно держать полную копию истории под рукой, а не на внешнем винте.
Если вы работаете в одиночку, то, скорее всего, вы сможете обойтись без веток, и у вас не будет «головной боли что там лучше делать merge или rebase». Жуткие номера коммитов (хэши)? В mercurial можно пользоваться последовательно возрастающим порядковым номером коммита, особенно если вы работаете один. Да и при использовании GUI, в принципе, можно и не заморачиваться этими обозначениями.
Некогда все это изучать? В mercurial описанный выше функционал под GUI клиентом можно освоить за день-два. Если не любите GUI и хочется консольного кунг-фу, вероятно, понадобится чуть побольше времени, но не намного. git в целом сложнее, чем mercurial, но на таком уровне особой разницы тоже не будет.
sshmakov
Мне кажется, что вы упустили существенную часть — наверное, вам также сказали, что перед тем, как сделать Checkout/Checkin, нужно обязательно сделать Show Differences, чтобы вы своими изменениями вы не затерли чужие.
pfemidi
Может быть. Это было давно, с тех пор у меня в этом практики никакой не было и я уже не помню, успешно всё забыл.
VEG
Попробуйте Mercurial. Он проще Git в освоении, и отлично подходит для проектов с одним разработчиком. Я сам его использую для сохранения истории разработки каждого из моих хобби-проектов на локальной машине. Удобно изучать историю изменений при помощи TortoiseHg (который на порядок удобнее TortoiseGit из-за Hg Workbench), скажем, через 5 лет после того как они были сделаны, и вы уже не помните что вы там именно делали и меняли.
iago
я пока не проверил 10 раз, думал это пишет мой отец. Вот все сходится — и программировать примерно тогда начал, и одиночка, и все новое и непонятное для него ненавидит! Вероятнее всего, вы сидите на старинных технологиях как и он, и на поддержке какого-то старого монстра, раз прогресс так далеко обходит вас стороной
develop7
Удваиваю mercurial, в git насильно реализовали сверхценные идеи торвальдса а-ля «головы DAG коммитов, на которые никто не ссылается — мусор» и держатся за них, как за спасательный круг. Что, если подумать, разумно, т.к. выкинь это всё — и git окажется просто ещё одной DVCS, только с неюзабельным интерфейсом.
aPiks
Если вам не нравится путаница с GIT, поставьте локальный SVN, создайте в нем одну ветку, поставьте Tortoise SVN и будет у вас тоже самое, что и сейчас, только гораздо удобнее. Не надо ничего никуда копировать, потом вытягивать и тд. Можно посмотреть различия в версиях файла сейчас и месяц назад. И для этого не надо выкачивать папку с датой и вручную сравнивать. Просто два клика мыши. Работаю над проектом один, а свой репозиторий проще поднять на SVN. С системой контроля версий работа становится намного проще.
MacIn
Вы могли бы использовать любые системы контроля версий — тот же SVN — в таком же стиле, просто используя одни и те же типовые приемы, без «этих ваших всяких непонятных cherry-pick». Но в дополнение получили бы внятную историю (changelog это совсем не то, слишком большая гранулярность). Как минимум. Какой-нибудь blame для старых изменений (посмотреть, в рамках какой задачи/коммита была изменена конкретная строка с сопутствующим комментарием) незаменим, и на директориях так просто этого не сделать.
Zarf
Не бывает так. Тролят нас!
Oxyd
Бывает, увы.
Self_Perfection
Про VCS не буду ничего говорить — выбор ваш.
Но может стоит хотя бы сменить формат даты на yyyy-mm-dd? С таким форматом даты сортировка по названию будет осмысленной и он стандартизирован — ISO8601.
pfemidi
Мне нет никакого дела до этого ISO8601, я в России живу, а в России формат даты ДЕНЬ МЕСЯЦ ГОД.
mayorovp
Тогда уж и разделителем точку используйте, а не минус.
pfemidi
А это уже привычка, в именах файлов/директорий после точки может быть лишь расширение. Но в дате всегда сначала идёт день, после месяц, после год, по-другому — от лукавого.
mayorovp
В дате российского формата части всегда разделяются точкой, всё остальное — от лукавого!
fshp
Кто вам эту ересь сказал? Расширение файла это лишь абстракция. И ни одна из известных мне современных файловых систем не реализует эту абстракцию. Она уже уровнем выше реализуется, на уровне приложений. Можно дать файлу имя "big.little.boss", никто этого не запрещает.
khim
Запрещает. Ещё как запрещает! В той же FDOS под имя файла отведено ровно 11 байт, 8 под имя и 3 под расширение, так ещё и от каждого байта старший бит занят под расширение. Да и даже в старой версии Minix вы такой файл не создатите (не более 14 символов в имени файла, однако).
fshp
Часто вы используете оригинальную fat? А может вы под minix программируете?
Изначально и дирректорий не было. Давайте не будем ими пользоваться.
pfemidi
Это не ересь, я же сказал что
Так что для меня всё что после точки то расширение.
fshp
Тогда извиняюсь, недопонимание вышло.
pfemidi
Наследие DOS, наследие 8.3. Я и к тому что имя файла может быть более чем 8 символов с трудом привык лишь лет пять назад. Против других ничего не имел, но свои называл строго не выходя за рамки восьми символов на имя.
saboteur_kiev
DOS не такая уж и старая операционка. Парралельно существовал вполне развитый Unix, файловая система которого уже тогда была case sensitive, уже тогда не имела такого ограничения на длину имени, и расширение как отдельный элемент также отсутствовало.
saboteur_kiev
А если mydocument.2011.12.11.txt, то где у вас расширение?
Self_Perfection
Какое вам дело до предпочтений других жителей России, если вы работаете над проектами один? Год в начале сделает удобнее вам (логичная сортировка) и из-за стандартизированности удобнее работу из кода с этим хранилищем ("%F" против "%d-%m-%Y" и т.п.).
iig
Зачем git, если есть архиватор.
Зачем сортировки по имени в своей же файлопомойке, если есть total commander.
pfemidi
Ещё раз. Я живу в России и для меня предпочтительнее принятый в России порядок день, месяц, год. Да, сортировка будет лучше, но у меня нет ни одного долгостроя, который продолжался бы более года, так что у меня сортировка не страдает. И т.к. я работаю один, то предпочтения других мне совсем не интересны.
TheShock
Похоже, у вас даже долгостроя в месяц не было, раз проблем с сортировкой не испытываете.
sumanai
То есть ни один проект не прожил больше года, раз поддержкой не занимаетесь? Или пишете сразу идеальный софт без единой ошибки?
pfemidi
Почему же, живут больше года, гораздо. Только поддержкой старого не занимаюсь, это да. Специфичные проекты просто.
fshp
Работал я как-то над "специфичным проектом". На Delphi.
Небольшой модуль для обработки изображений.
Переменные были объявлены с "запасом".
Около 60 переменных объявлено, из которых использовалсь около 20. У и по классике: они назывались x1, x2, x2, ..., a1, a2...
Что бы не иметь проблем с выходом за границу, массивы были объявлены размером в 10 раз больше нужного.
Кусок кода размером более 1000 строк состоял из 3 процедур (не функций). Передача результата через глобальные переменные.
Естественно никакого версионирования, все по папочкам.
Читать изображения разработчик этого модуля не умел, поэтому для него был написан отдельный конвертер, который jpg в текстовом виде представлял.
Я пытался указать на ошибки, однако получит в ответ что-то вроде: "Я 30 лет программирую, у меня 600 патентов, больше 100 реализованных проектов. Я к.ф.-м.н. Да тебе лет меньше, чем я в отрасли". На чем мои попытки благополучно закончились.
iig
Человеческий детёныш, воспитанный диким Fortran-ом ;)
Знакомо.
Таблицы у нас именовались незатейливо: m1,m2,..m199… (сотни их было)
Поля в таблицах — по аналогичной схеме: R01,R02…
3 разработчика, никакого VCS.
Теперь то я понял, что это был своеобразный developer lock.
nmrulin
За это Дельфи и убили — что даже такой человек мог выдавать относительно работающий код, который можно было относительно легко читать и понимать. Правда, всё — равно таких программистов, как в вашем примере много. В куче игр каждое сохранение по 10-20 мегабайт, при том, что реальной информации и на 1 Кб не наберётся. Но теперь их легко вычисляют и берут осознанно для экономии.
WraithOW
ГОСТ ИСО 8601-2001 «Представление дат и времени»
saboteur_kiev
Если вы работаете один, вам вообще не нужны ни ребайзы ни черрипики, вообще базовый гит, который за два часа можно освоить
Просто банальные git commit, git diff, git log и отдельно git branch, git merge
Потом внезапно еще освоите git clone/git pull/git push и сможете легко работать с любой машины, а не только с одной.
Oxyd
Боюсь угадать, это не какая-нибудь (около)государственная контора, для которой вы пишете проекты?
pfemidi
Не бойтесь, не угадали.
zagayevskiy
Бисект (бинарный поиск по коммитам) нужен, когда вы не знаете, в каком коммите ошибка. Не знаете, в какой день она допущена, и при изменении какого куска кода.
sergeysm128
Я когда впервые пришел на работу то обменивались через USB-флешку)) Потом работали или по очереди или над разными модулями выгружая/загружая все на продакшен. Я тоже долго откладывал знакомство с Git, но когда познакомился, то вспоминал былые времена как страшный сон. Жалел что раньше не познакомился, тогда я бы в Git держал бы и курсовые (а не копия, новая копия новая копия 2)
KvanTTT
За 30 лет то можно было найти время. Ничего там сложного нет, особенно на базовом уровне.
khim
Вместо этого удалось как-то найти проект (или проекты), где можно работать одному. Это, я считаю, куда больший подвиг, чем изучение Git'а или там китайского языка.
Так-то я никогда не сталкивался с проектами, которые можно годами «пилить» одному. В моей практике как-то так получалось что либо проект «взлетает» и над ним работают 3-5-10-100 человек (в зависимости от того, как хорошо он «взлетел»), либо падает — а тогда там ни одного разработчика не нужно.
Про уникальный проект, где можно годами работать одному можно, видимо поэму написать — это ж редкость невероятная.
KvanTTT
Работа над проектом в одиночку уже считается подвигом? Что за проект то хотя бы?
khim
Нет — подвигом считается возможность работать над проектом в одиночку. Ибо я не представляю себе как так может быть, что проект годами и не закрывается и не расширяется… если, конечно, это не ваше хобби, которым вы занимаетесь по ночем и никому не показываете…
А что за проект — мне тоже интересно узнать…
onegreyonewhite
Если проект в какой-нибудь госконторе, то это почти типичное явление. Я уж молчу про 1С (7.7) и небольшие магазины, ТСЖ и т.п. К сожалению, часто вижу небольшие фирмы, где всё так устроено и руки чешутся им помочь (хотя возможно это аллергия на old-school-legacy).
khim
Понятно… Что можно сказать…
Если вы собираетесь в такой компании работать до пенсии… то не всё ли вам равно — что о вас думают в других местах?
Whuthering
Вы-то можете собираться работать там до пенсии, но компания может обанкротиться, вы можете попасть под сокращение, или сменится руководство и работать станет невозможно, или еще что, вариантов сотни. А пенсия всё еще не прям завтра.
И вот вам уже резко станет не все равно что о вас думают в других местах, когда выяснится, что вы с вашим весьма узкоспецифическим багажом мало где нужны.
khim
Люди, смотрящие так далеко вперёд обычно в компании, где нет никакого роста (компании, не человека) не сидят.
Skerrigan
Не автор, но,… платформа «автоматизации тестирования» (AST).
Java (+ Hibernate, Maven, WebDriver, Jersey, OAuth2)
PHP (+ Smarty, Composer, SafeMySQL)
JS (+ NPM, Webpack, Babel, Vue)
SCSS-препроцессинг (для веб-интерфейса), микросервисы, динамическое распределение нагрузки (самописный балансир).
В марте будет как 6 лет работы «в одного».
aPiks
У меня знакомый один работает уже 10 лет над одним проектом. Начал магазин с PHP и MySQL, а сейчас уже NodeJS, Angular 4, PostgreSQL… И владелец сайта доволен и человек всегда при работе и получает очень неплохие деньги.
khim
Вот про это было бы интереснее узнать. Что госконтора может годами не меняться — это примерно понятно. Но как сайт умудряется и не вырасти с одного разработчика до сотни (за 10-то лет!) и не закрыться (за 10-то лет!) — решительно непонятно…
aPiks
Сколько вам потребуется время для того, чтобы запилить качественный сайт в одиночку? Например, фрилансеры на апворке с хорошей статой — за полтора месяца. Ну вот, он запилил, доделывал какие-то вещи, а потом с нуля второй, третий и тд, пока на современные технологии не переехал. И процесс продолжается. Посетителей у него где-то 10 тысяч в день, а больше и не надо. Человек не гонится за ростом особо. Ну а вообще, хотелось бы у вас узнать сколько айти людей надо, чтобы поддерживать сайт? Я так представлю себе: один фронт, один бэк, может быть еще SQLщика одного и рекламщика. Ну и первые три из этой компании могут быть замещены опытным фулл-стэком, а последнего можно на стороне нанять, чтоб рекламки делал, вот и всё.
khim
Если сайт у вас некоммерческий, то там и одного человека час в месяц может хватить.
А если у вас магазин, то вам нужно либо расширяться, либо, если это не удастся, вас сожрут. Представить себе интернет-магазин, который 10 лет остаётся на том же уровне продаж мне довольно сложно, потому и возникает интерес: что за магазин, зачем ему новые технологии (если он продаёт что-то уникальное на что в природе тысяча покупателей ежемесячно и больше — нет и не будет, то зачем ему редизайн?) и так далее.
Просто уж очень необычный случай, вот и всё.
aPiks
Допустим, вы торгуете элитной мебелью где-нибудь в Андалусии, Испания. У вас есть интернет магазин, который скорее не магазин, а онлайн-каталог, потому что в основном все любят потрогать, пощупать. Конкурентов у вас не так много, поскольку вы работаете напрямую с изготовителями и сделать мебель дешевле уже не получится. Вы не хотите идти в большой бизнес, потому что там надо много людей нанимать, управлять всем этим и тд, а вам же хочется, чтоб хватало на свой дом у моря, пару машин, да семью содержать. Вы находите очень хорошего программиста и предлагаете ему заниматься сайтом в долгосрочной перспективе, поддерживая его красивым, современным и тд, ведь это элитная мебель, значит и впечатления от сайта должны быть соответствующие. Этот программист берется за работу, периодически нанимает дизайнеров для обновлений внешнего вида, и обновляет начинку сайта, дабы все это работало быстро и как надо. Все остальное время программист задействован в поддержании всего этого добра на плаву, меняя, обновляя и модифицируя по надобности. Вы, как владелец счастливы, потому что ваш онлайн магазин всегда под присмотром и работает как надо. При этом вы не платите много какой-то левой компании, которой надо кормить 10 менеджеров и оплачивать работу такого-же одного программиста.
Вы, как человек, который знает половину дизайнеров и строительных компаний в этой самой Андалусии, без заказов точно не останетесь, а если делаете свою работу хорошо, так и подавно.
Ну а теперь, возвращаясь к вашему вопросу, вы — это тот самый владелец магазина, о котором я писал, а программист одиночка — мой знакомый. Живёт в той самой Андалусии и работает уже больше 10 лет над одним проектом.
khim
Спасибо. Да, пожалуй что в этом случае такой подход может и сработать. До кризиса в Андалусии, понятно, но тут уж непонятно: некоторые мелкие княжества в Европе умудряются существовать столетиями, не разваливаясь от глобальных кризисов.
Так что случай реальный, но слегка экзотический…
0xd34df00d
Можно даже показывать, но всё равно работать в одиночку. Есть у меня один такой проект…
MicroNovaX
А на работе что используется? FTP-шечка с CHANGELOG.txt?)
spam312sn
Может быть вам стоит посмотреть вот этот интерактивный учебник: https://learngitbranching.js.org/. Поверьте, Git — это мощный и удобный инструмент, который не потребует от вас каких-то специфических знаний. Если вам сложно в консоли с ним работать — есть отличные инструменты встроенные в VisuaStudio, Intelij IDEA и прочие IDE, так же есть GUI инструменты для работы с ветками и коммитами — https://git-scm.com/download/gui/linux, некоторые из них позволяют разрешать конфликты слияний прямо внутри себя.
Так же, могу вам посоветовать Git Flow, когда вы будете готовы к приятному и понятному распараллеливанию процессов изменения вашего кода.
Надеюсь вам станет немного комфортнее в работе, потому что у меня мурашки пробежали по спине от вашего комментария — я когда-то уже терял многие изменения кода и было досадно от того, что приходилось делать двойную работу
arabesc
KvanTTT
Удивительно что этот комментарий собрал столько плюсов, хотя дальше в дискуссии такой подход только раскритиковали.
pfemidi
Я сам удивлён, ожидал тонны минусов и полный кармагеддон сразу же после написания именно этого комментария. Но на него почему-то пошли плюсы. Зато тонны минусов посыпались на последующие. Ну да ладно, «каждый кулик своё болото хвалит», я сказал как у меня, народ сказал (минусами и понижением кармы) как у него. Так что дискуссию считаю завершённой, пойду дальше делать бекапы исходя из конкретной даты. Потому что мне так удобнее и слава богу работодатели не требуют от меня изучения ни git, ни hg, ни svn, им надо не шашечки, а ехать.
mayorovp
Уточнение: вы не только сказали что вам так удобнее (хотя это уже странно), но и наговорили кучу глупостей о гите. А когда вам попробовали подсказать как можно сделать всё еще удобнее чем было — и вовсе начали огрызаться, даже не попытавшись разобраться в том что вам говорят.
pfemidi
1) Я не говорил «кучу глупостей о гите», я говорил о том, как его вижу. А вижу я его именно как средство для искусственного усложнения того, чего можно сделать (и я делаю) гораздо проще.
2) Я не начал огрызаться, я просто сказал как я делаю, а в последующих комментариях я просто повторил как я делаю специально для тех, кто с первого раза не понял и начал меня учить чтобы я попробовал то, попробовал сё, изменил свой подход и т.д.
Так что для меня всё равно тайна за семью печатями почему исходный комментарий заплюсовали, а последующие, в которых речь шла абсолютно о том же самом что и в исходном, были заминусованы. Но я за эти минусы ни на кого не обижаюсь, каждый волен выбирать то, что ему нравится и высказывать своё мнение пусть не словами, а минусами.
Lissov
Исходный комментарий заплюсовали (и я в том числе) потому, что он біл ответом на некорректное утверждение что кто не знает гит — не профессионал. Остальные заминусовали потому, что дальнейшие попытки доказать, что гит не нужен вообще, выглядят странно для тех, кто гит знает. Можете пробовать гит, можете не пробовать, дело Ваше.
saboteur_kiev
Простите, но как
git commitможет быть сложнее
rar a file_with_new_version_name.rar /myproject/dirТем более, что по времени выполнения и занимаемому месту git будет однозначно быстрее. Вдобавок я просто не представляю сколько времени вы тратите на то, чтобы сделать сравнение версий.
mayorovp
Уточнение:
git commit --all -m "new_version_name"iig
Тогда уж -m «fixed some bugs, implemented some features»
mayorovp
Т-с-с! Не пугайте динозавра.
saboteur_kiev
ну если придираться, еще и git add и git rm может понадобиться, --all сам по себе файлы не добавляет.
Whuthering
У вас просто очень узкоспецифичный и редкий случай с командой продукта из 1-го человека.
А в остальных же случаях в том-то и дело, что VCS нужны как раз-таки чтобы ехать. Картинка с круглыми и квадратными колесами ниже весьма метко характеризует ситуацию :)
MTyrz
Знаете…
Недавно я столкнулся с проблемой, которую решить пока не сумел. Хороший знакомый, всплывший из длительного необщения, сотворил систему работы с данными, как ему удобнее.
Я, собственно, не столько критиковать, сколько поделиться. Есть чертова уйма офисных файлов и (кажется) ПДФок. С большим количеством значимого текста.
Помимо этого есть куча папок, в которых лежат ярлыки — ссылки на нужные фрагменты нужных файлов. Папки тематические, они тоже связаны уймой перекрестных ссылок, реализованных тоже ярлыками. На каждый файл могут быть сотни таких ярлыков в разных папках, указывающие на разные места файла. Вся организация информации реализована на этих, мать их, ярлыках.
Ему так удобнее. Это цитата, да.
Файлов много, он реально работающий биолог. То есть, тысячи, может быть первые десятки тысяч. Библиотека на жестком диске, плюс его собственные данные. Творил он это все лет десять, и после перехода с XP на семерку вся эта радость работать перестала.
Совсем.
И что с этим адочком делать, я в душе не чаю. Зато ему было удобнее, долго было…
staticlab
Семёрка (и Виста) не поддерживает фрагменты. Здесь видится такой вариант, что может потребоваться написать специализированную базу данных с импортёром, который можно было бы запустить на XP, и он бы перегнал shs-файлы (с помощью shscrap.dll) в эту базу.
MTyrz
Спасибо, покурю в этом направлении. Может, что получится.
staticlab
Только, боюсь, это очень много труда потребует. Но решение может стать солидным движком базы знаний.
poxvuibr
Ставить XP в виртуальной машине, думаю.
MTyrz
Пробовал, не взлетело.
Что-то ему не занравилось в возможных способах обмена файлами гостевой и хостовой систем. Пробовали XP Mode, пробовали VmWare: неудобно.
В итоге он все же засел за пересмотр своих воззрений. Жду, к чему пересмотр приведет.
saboteur_kiev
ЧТО там может непонравится? общая папка, и тупо работает…
MTonly
Оборот «уметь в» — вообще характерный признак продвинутого разработчика. :D
fOCUS_VRN
Умею нажимать в русской версии VisualStudio «Синхронизировать», что автоматизирует последовательность «принести», «вытянуть», «отправить»
ЧЯДНТ?
DieSlogan
Вы путаете «не умеет» с «не хочет»
sborisov
Интервью Кузнецова было на opennet(это тот мужик, который написал сетевой стек Linux) — он там про гит и Линуса рассказывал, говорил что при всех недостатках, Торвальдс умеет видеть далеко вперёд, и там где многие разработчики видели навоз (так он называл bitkeeper), Линус смог разглядеть бриллиант и сделать на этих идеях git.
ainoneko
(Где-то ещё было сравнение git с навороченным гоночным мотоциклом, на котором легко убиться, но можно и безопасно ездить вокруг гаража.)
sborisov
Как мне кажется, Линус писал эту систему под конкретные задачи, с чем она отлично справлялась.
Вспомните, ведь даже версия под Windows появилась много лет спустя.
Модель работы многим понравилась и её масштабировали на весь мир OpenSource (Mercurial тоже не забываем). А в коммерческую разработку ворваться Git в немалой степени помог Github.
develop7
github и бездумное копирование подходов, принятых в больших проектах/компаниях (git, микросервисная архитектура, kubernetes и проч.)
saboteur_kiev
Да ладно, гит неплох, сделан от души, но у него есть множество достойных конкурентов. Просто гитхаб зарулил.
А так, если копнуть глубоко, то вместо архивации всей папки с проектом, вполне можно пользоваться и svn и CVS и более старыми системами, тот же SCCS более продвинутый по возможностям, чем CVS, а появился гораздо раньше.
Arastas
Как мне организовать работу в git над текстом, если некоторые соавторы не хотят и не будут?
staticlab
Даёте им исходную версию текста. Они делают там какие-то правки. Возвращают вам промежуточную версию. Вы создаёте отдельную ветку и заменяете там исходный файл на их версию. Коммитите, затем мержите в мастер-ветку. Сразу же отдаёте смерженную версию на последующие правки.
Видится только такой вариант, потому что пользоваться веб-версией репозитория (на условном гитлабе или гитхабе) они вряд ли будут.
ainoneko
balexa
А надо понять для чего. Если вам действительно нужно хранить историю версий, смотреть кто что и когда заменил, откатываться и разбираться, то все авторы скорее всего с радостью перейдут на это сами. Если же просто «чтобы было» — то может его и внедрять не надо?
marsermd
Причём у гуглдоков уже есть версионирование:)
HSerg
Обычный текст без форматирования или какие-нибудь word-файлы?
P.S. Для совместной работы над текстами лучше подойдёт какая-нибудь wiki.
Aingis
У вики плохо с конфликтами. Например, кто-то нажал редактировать, сделал правки, а в это время текст кто-то ещё отправил свои. При отправке вики ругается на конфликты, изменённый текст только в браузере, и может легко потеряться. Либо сторонние изменения просто затрутся. В гите хотя бы будут ветки с коммитами, информация не потеряется.
HSerg
В последнее время работал с confluence — в ней нормальное разрешение конфликтов при сохранении и есть автосохранение черновиков.
Alexufo
Вики не то. Word отлично умеет многопользоваться, другое дело что большинство закладку рецензирование предпочитают не замечать.
spam312sn
А что, если вам попробовать GitBook? Там поддерживаются версии, можно разрешать конфликты слияний интерактивно, история изменений и самое главное — можно создавать приватные проекты и работать в них, имеетcя интеграция с Github.
Могу ещё посоветовать Confluence от Atlassian
nmrulin
У нас лет 10 делали так — тимлид выдавал версию проекта, остальные, соотвественно, делали модули и отсылали ему.
Alexufo
Текст? Word — рецензирование, объединение версий. Сравнивает не хуже Гита.
khim
Они, я извиняюсь, как кит и слон. Для текстовых файлов Git — много удобнее. Для структурированных (XML или документа Word) — почти не применим. Word работает только со своими файлами, но если у вас там не просто текст, а какое-то форматирование и прочее, то сравнивать с Git'ом это просто нельзя.
Alexufo
конечно, если текст с маркдауном каким нибудь то конечно гит. Просто объединение изменений в ворде тоже проходит с посимвольной точностью с возможностью указания необходимости сравнения и стилей оформления.
firk
git возможно и хорош для свободной базарной разработки (как у линукса), но для системы с жёстко централизованным репозиторием, каковая имеется, как мне кажется, в большинстве проектов, это перегруженная кучей лишних «фич» гадость (и «инструкция как коммитить» в начале статьи — наглядный тому пример), но при этом не умеющая из коробки такие действительно нужные вещи как нормальное управление доступом и его логирование.
Идеология subversion на мой взгляд намного лучше подходит для таких случаев, а git просто модный и распиаренный всякими гитхабами. В сожалению, из-за распиаренности иногда некоторые инструменты ориентируются эксклюзивно на него, что даёт ему дополнительные преимущества, но это не заслуга самого гита а лишь следствие его модности.
rkh
Простите, можно поподробнее о том, что умеет svn и не умеет git?
maisvendoo
sarcasm mode on
Наверное полностью парализовать работу команды при падении центрального хранилища
sarcasm mode off
Git — децентрализованная система контроля версий, это её главное преимущество
litwr2
Если git-сервер рухнет, командная работа с git упадет и никакие локальные коммиты не помогут. Единственное достоинство git и др. распределенных систем в том, что если сервер упадёт навсегда (хотя обычно такое абсолютно невозможно), то будет возможность многое восстановить на возрожденном сервере. А главный недостаток и так все знают — много всяких замороченностей ради возможности иметь упомянутое выше достоинство. А если вы работаете в одиночку, то, имея сервер на своем компьютере, разницы между git/hg/… и svn/cvs/… вообще не найдете, кроме больших заморочек с первыми.
mayorovp
А если рухнет svn-сервер, но упадёт не только командная работа, но и вообще любая работа. В этом и заключается основная разница между git и svn.
А ещё git позволяет делать промежуточные коммиты для сохранения промежуточного состояния, когда выкладывать свой код я еще не готов, а сохранить куда-нибудь его уже не помешает. Что, в свою очередь, позволяет забыть про проблемы с «дикими» инструментами вроде Telerik Reports Designer, которые «славятся» тем что регулярно необратимо портят редактируемые файлы.
Так что если вам какие-то возможности git показались ненужными — это еще не значит, что эти «замороченности» и правда никому не нужны. Я вот именно из-за них даже с svn-репозиториями через git работаю.
litwr2
Промежуточные коммиты? Но они же все равно потом пойдут в общий репозиторий, если это коммиты, а не сташи. Штучек, ломающих репозитории, ради поправок в «неправильных» коммитах немало везде. Извините, но у меня представление такое, если не работает сервер, то это в 99% случаях не работает сеть. Никакой нормальной работы сегодня или даже 5 лет назад без сети не представить. Но если случится 1%, когда именно просел на часок-другой только сервер, и очень хочется сделать коммит, то из-за редкостной диковинности такой ситуации можно чуть-чуть побольше сделать, а именно скопировать каталог для его дальнейшей отправки на сервер, когда тот заработает, — неудобство, но редкое и незначительное. GIT интересный инструмент, действительно, учитывающий очень много тонкостей, но это не значит, что другие VCS как-то хуже, они — другие. DVCS реально повышают надежность, особенно больших проектов типа ядра Linux и это очень существенно, но есть и другие способы повышать надёжность.
mayorovp
Существует же
rebase --interactive.От проекта зависит.
arabesc
mayorovp
Ну, не я первый начал писать про рухнувшие сервера.
А вообще, на самом деле у нас такое регулярно бывает, ибо основной svn-репозиторий лежит за двумя vpn и в другом часовом поясе, к тому же админится не нами.
BalinTomsk
Помню видел лекцию где Linus пытался уговорит гуглевцев перейти на Git с Perfoсe.
Ни одного преимущества Git так и не прозвучало.
Надеждость централизованной системы давно и легко обеспечивается бэкапами и распределенными с серверами.
mayorovp
Ну так расскажите, как вы будете делать распределенный svn. И как собираетесь бороться бэкапами с сетевыми проблемами…
BalinTomsk
А кто вам сказал чтo SVN? Я пользуюсь и SVN в том числе, на самом деле ужасный продукт.
Perforce используют организации с десятками тысяч пользователей. Неужели вы думаете, что в гугле не сумели организовать надежность централизованного сервера?
khim
В Гугле как раз очень долго боролись с тем, чтобы избавиться от центрального P4-сервера. Ибо какое-бы-железо-там-ни-было, но оно может отказать.
BalinTomsk
Есть 100500 способов обеспечить бесперебойную работу сервиса (Google мне кажется в этом вполне преуспел), странно что это приходится обьяснять на Habr-e.
Я не помню что бы за годы работы в RIM я хоть раз терял данные в P4.
khim
И, тем не менее, Гугл в качестве варианта решения проблемы предпочёл отказаться от P4
mayorovp
Этот сказал тут хабрапользователь, который начал эту ветку обсуждения:
Тут сравнивается именно svn и git, а не Perforce и git, и даже не hg и git.
staticlab
Git может работать по почте.
mayorovp
Только на линуксе. Под виндами какая-то непонятная фигня с окончаниями строк получается, каждый раз когда я пытался — коммиты приходили битыми.
Возможно, его и можно как-то правильно настроить для работы по почте — но точно не в ситуации когда центральный сервер внезапно рухнул. Проще новый сервер поднять.
fshp
Отправляйте патч вложением, что бы почтовый клиент его не попортил, а в настройках гита пропишите core.autocrlf
mayorovp
Я патч передавал вообще по Скайпу, сомневаюсь что проблема в канале передачи.
Что же до core.autocrlf — у нас он включен. Кажется, в этом и проблема.
arabesc
Наверное, в случае децентрализованной же разработки, когда человек сидит с ноутом под пальмой без доступа к сети, но имеет доступ к локальному срезу репозитория, может потом в отдельные моменты времени синхронизироваться. Наверное, характерно для open-source разработки, где всё это родилось.
А в контексте организации зачем держать у каждого весь репозиторий? Рухнет сервер? Это вообще не проблема VCS, отказоустойчивость нужно повышать другими методами.
mayorovp
Дополнительные офисы. Удалённые разработчики. Аутсорсеры и фрилансеры… В случае разработки на заказ — ещё и заказчик. Всем им нужна копия репозитория, иначе при любых проблемах с инетом работа может встать надолго.
HSerg
В git действительно нет управления доступом внутри репозитория. Или всё, или ничего.
rkh
О, спасибо, не знал.
khim
Это, кстати, было сознательным решением и, как показывает опыт — правильным. Ограничение на запись в git не особо нужно, так как рекомендуется использовать не «написанный на бумажке» git push, а таки, в основном, git pull — когда тот, кто «берёт» у вас изменения на них смотрит и отвечает… но если нужен git push — то можно использовать commit queue.
А вот невозможность «бесплатно» закрыть кому-то доступ обозначает, что такая операция получает вполне себе ненулевую цену, которую можно процитировать менеджерам и, особенно, лигалам когда они порождают очередные безумные идеи в попытке «прикрыть свою задницу».
Это — очень полезно, как показывает практика: если-таки закрыть действительно нужно — то это делается (через submodules, repo и разными другими способами), но вот обоснования «как бы чего не вышло» — уже не прокатывает… нужно реальное обоснование.
F0iL
Но это вполне решено в Gerrit или Gitlab, например. И access control по группам, и commit-queue, и много чего еще.
HSerg
Насколько помню — в GitLab нельзя закрыть какую-то часть git-репозитория на чтение.
С Gerrit у меня как-то не сложилось… В нём можно при git clone получить только разрешённую часть репозитория (и истории соотв.)?
lorc
Да нет, нельзя. Это в принципе нельзя, потому что внутрення структура данных гита не позволит. Гит хранит слепок состояния всего кода как один объект. Можно, конечно вырезать оттуда лишнее, но тогда поедут все хеши всех коммитов. Да и накладно это — надо будет делать replay всей истории. И непонятно как потом заливать изменения обратно.
danfe
Karl_Marx
Lock же.
Ни одна децентрализованная система его не поддерживает, по крайней мере без костылей. В .Net, допустим, есть Entity Framework 6 и EDMX-модели, которые нереально мержить, это огромный XML с описанием иногда тысяч сущностей в базе данных и их взаимосвязей, он редактируется только с помощью специального визуального редактора. Когда один разработчик вносит изменения в схему БД, в SVN или TFS он делает Lock этого файла и другие разработчики не могут его изменить, а если он использует Git, он делает коммит, попадает на конфликт и идет выяснять в честном поединке, кто будет коммитить первым.
mayorovp
Когда я работал с edmx, я периодически мержил edmx-модели. Ничего сложного, там довольно простой формат.
Самое противное — когда новая версия визуального дизайнера решает упорядочить сущности в новом порядке. Но это решается одинаковой версией студии у всей команды.
Вот что действительно сложно мержить — так это миграции БД. Но там и лок повесить просто не на что...
khim
Я тоже пришёл в git с P4, где есть права доступа и вот это вот всё… и после нескольких лет понял, что при переходе на git одно из самых важных вещей, которые пришлось сделать — это поделить проект на компоненты. При этом можно быть уверенным, что если вы что-то внутри компонента меняете, то вы гарантированно видите все последствия — чего не было с P4.
Ну а между компонентами — да, приходится налаживать взаимодествие. И невозможность быстрого «забивания костыля» с закрытием доступа к файлу config.cpp в котором пароль-к-важной-базе лежит заставляет делать «человеческие» решения.
Так что невозможность ограничить чтение — это, скорее, достоинство.
Ограничения же на то, куда кто может писать… легко делаются через Commit Queue — что, опять-таки, энфорсит правильный подход: CQ-бот не даст вам возможность залить код, который тесты не прошёл (ну или даст, но отправит сразу же репорт «кому надо»), что тоже очень полезно.
arabesc
Не понял, какая связь между делением на компоненты и VCS? Что такого позволяет видеть Git, чего не давал P4?
Собственно, одна из целей деления на компоненты, это инкапсуляция деталей реализации, как раз сокрытие внутренностей.
firk
Тут все почему-то решили что «нормальное управление доступом» это разграничение доступа по файлам внутри репозитория. Ну да, про это тоже можно было написать, но о таком я, так сказать, от гита даже и не мечтал. У него всё намного хуже. А именно, управления доступом нет ВООБЩЕ.
То есть, если кто-то вообще смог подключиться к репозиторию (и смог/не смог тут решает не гит), то ему сразу всё доступно. Ограничения могут возникнуть только в случае если нижестоящий слой хранилища (файловая система) тупо не даст модифицировать файлы репозитория с теми правами, с которыми запустился процесс гит-клиента.
При этом сам гит вообще не имеет никакого понятия о том, что к нему подключился кто-то конкретный — для него все юзеры по сути анонимны.
Все способы устранить эту проблему неизбежно приводят к использованию какого-то доп. софта, и я не знаю даже, есть ли способ прикрутить его к гиту не традиционно-костыльным способом и не патча сам гит на сервере.
> одно из самых важных вещей, которые пришлось сделать — это поделить проект на компоненты
Смотрится так, как будто руководитель разработки такой дурак, сам не знает что ему надо, а умный гит его заставил сделать правильно. Решение организационных проблем техническими методами? По-моему инструмент должен реализовывать запросы его использующего, вне зависимости от их разумности, а не вынуждать его менять их.
khim
Но что тут нелогичного? Репозиторий — это, я извиняюсь, каталог с определённого вида данными. Если мы не хотим устраивать систему прав «внутри» этих данных, то какие проблемы с тем, чтобы использовать подсистему, которая, собственно, и предназначена для того, чтобы ограничать доступ к файлам и каталогам?
Вы так и не сказали почему это, собственно, проблема.
Нет. Оно так не работает. Если есть техническая возможность что-то сделать через… одно место — то этим непременно кто-то воспользуется. Рано или поздно. Если есть техническая возможность запретить что-то делать неправильно — то лучше это сделать на уровне техники.
В конце-концов вы же, почему-то, не считаете проблему прав доступа решаемой с помощью бумажки, вывешенной в коридоре, где написано — куда может писать Петя, а куда Вася… так почему в данном случае вы считаете, что ограничение «руководителя разработки» с помощью «технического средства» — это плохо?
firk
Ну, с таким подходом всё встаёт на свои места. Если преподносить гит как движок базы данных для системы контроля версий — то всё так и есть. Действительно, он знает как проводить нужные операции над данными, а остальное его волновать не должно.
Ну и
для встраиваемой библиотеки движка базы это и правда не проблема.
Но он почему-то везде преподносится как готовый standalone продукт. (у движка базы в первую очередь должно продвигаться и документироваться низкоуровневое api для обращения к нему из приложений, а вовсе не утилиты для командной строки).
А к готовому продукту требования уже (у меня по крайней мере, но думаю это разумно) совсем другие.
Например, от любой коллективно используемой ИТ-системы (не важно, vcs это или нет) я ожидаю наличие логов важных действий — с указанием, кто (логин, возможно адрес), когда и что (в данном случае список запушенных коммитов) сделал. И не прикрученных какими-то костылями, а реализованных монолитно с остальным исходным кодом приложения.
Да, но издавать запреты это прерогатива начальства того сотрудника, которого эти запреты касаются, а вовсе не авторов инструментов. А если начальства нет и проект свой собственный — то вообще непонятно с чего бы кто-то решил мне запрещать его вести так как мне нравится, пусть даже и по чьему-то мнению я делаю это неправильно.
Собственно, я не против ситуации, в которой начальство, отчаявшись заставить своих сотрудников делить проект на компоненты, заставляет их пользоваться гитом с которым по-другому не получится. (хотя неудача в мирном решении данной проблемы наводит на мысли о некомпетентности этого начальства) А вот ситуация "указа не было, по пришлось из-за особенностей инструмента" уже мне совсем не нравится.
khim
Git изначально создавался как база для других Scm… но потом выяснилось, что того, что есть — в принципе и так достаточно.
Ну это уже вкусовщина. В UNIX ситуация, когда программа общается с другими программами вызывая их и передавая параметры в командной строке не считается чем-то странным и необычным. И Git был под этот сценарий заточен…
Тем не менее эта ситуация гораздо чаще встречается, чем все остальные…
vmarunin
github или gitlab или ещё тысячи их везут с собой центральный репозиторий с доступом, логгированием, CI/CD, code review и т.д.
Наша компания переехала с SVN на git (одно время был и git и mercurial). Всё что мы использовали в SVN нашли и в git c обвесом.
Если пилить одному один кусок кода то svn вполне хватает, но как только один файл начинает использовать много народу, так начинаются проблемы.
dipsy
Хорошая статья и диаграммы наглядные. Кажется я впервые (с 10 примерно по счету прочитанной обзорной статьи) понял, зачем мне мог бы понадобиться гит и как с ним работать. Сейчас команда, с которой работаю, использует TFS и SVN, с ними вообще очевидно всё (то, что ожидаешь от СКВ): правишь у себя; сливаешь с общим репозиторием; видишь всю историю изменений; есть возможность откатиться на любую версию. С глобальным репозиторием видимо удобнее такое вот дополнительное "кеширование", как в гите, хотя я его и так у себя настроил давно с SVN: коммичу в локальный репозиторий на своем ПК каждое изменение; сливаю с общим сетевым по завершению какого-то логического этапа разработки (компилирующийся и протестированный код).
click0
Я бы еще добавил к списку ресурсов — Git Command Explorer.
Он в интерактивном режиме спрашивает разработчика, что он хочет получить-изменить и подсказывает необходимые git команды.
MrGobus
Суховато. Суховато даже для носителей языка, не говоря уж о нас, простых смертных. Тот самый случай когда после ознакомления я сделаю вид, что все понял, но продолжу клеить бумажку.
BiosUefi
>>Тот самый случай когда после ознакомления я сделаю вид, что все понял, но продолжу клеить бумажку.
— в нашем суперпродукте есть 300 новых перделок и 800 новых свистелок, отсутствующих в продуктах конкурентов
— простите а как мне выполнить последовательность 1-2-3-4?
— выучите все наши сакральные «перделки» и кошерные «свистелки», тогда вы сможите даже 1-2-3-4!
PS: Ни каких намеков… это всего лишь сравнение MS Оffice 97 и 2019.)))
Qilicad
Не совсем понимаю популярность этого Git. Пробовал пользоваться — долго плевался. На работе стоит TortoiseSVN — простой, понятный и логичный. А Git какой-то надмозговый.
litwr2
Можете попробовать Mercurial. Oн внешне, для пользователя почти как Subversion, а внутренне это почти GIT. Разницы особой не заметите, но это будет DVCS. Кому-то нравится мыло, а кому-то шило. :)
spam312sn
В подтверждение ваших слов, могу добавить, что в свой самый первый раз использования VCS я познакомился с Mercurial, и только несколько лет спустя перешёл на Git. Абсолютно никаких неудобств с использованием и того и другого
F0iL
Если есть неприязнь к консоли, под виндой точно так же можно использовать TortoiseGit.
springme
Пользуюсь IDEA/WebStorm – там есть прекрасная встроенная поддержка гита, для 99% случаев хватает. Для остальных стековерфлоу и крепкие нервы. Таких как я, наверное, большинство.
Лично мне учить гит ради гита не интересно, сколько ни пытался – всегда бросал. Тем не менее жизни без гита, а тем более версионирования представить не могу.
geisha
Аналогично, вместо выучивания команд просто установил гиткракен gui. Во-первых, там есть кнопочка Undo, во-вторых, он сам подтягивает обновления с гитхаба: сразу видно, кто, что и сколько сделал, в-третьих, с помощью gui начниаешь узнавать о полезностях гита — stash, разрешение конфликтов и т.п. Я бы даже посоветовал гиткракен если бы не этот сраный Electron.
staticlab
Тогда SourceTree.
geisha
Не для линуксов и 75 мегабайт как-то подозрительно выглядят. Это, конечно, не сборка хромиума, но оно явно поставляется с исполняющей средой JRE, .NET, Qt или чем-то там.
staticlab
Нет. SourceTree для Windows хоть и написан на .NET, но с ним не поставляется. Там одни только дллки для TFS на 10 Мб, жирненькие дллки темы WPF, локализации на 5 Мб, вдобавок он разворачивается из nuget-пакета, и он фактически дублируется (50 Мб распакованный + 23 Мб в nuget).
А вообще лучше всего консоль + bash-git-prompt. Жаль только на винде оно медленно работает.
mayorovp
Лучше всего — Git Extensions. Там в последних версиях ещё вкладку с консолью приделали, стало совсем удобно.
Oxyd
Я давно на связке ZSH + Oh-My-Zsh, в котором, в том исле есть и плагин для гита. [holywar]Как люди живут в это вашем bash, не понимаю.[/holywar] ;-)
hoobastank
Я наоборот начинал с командной строки. Ну, кроме диффа/коммита. А потом понемногу начинал пользоваться остальными командами из UI, когда убедился что они делают то что нужно. Мне наоборот спокойней, когда я понимаю, что происходит под капотом, а не «VCS/Update», который непонятно что сделает с веткой. Да и поддержка всех нужных функций в IDEA появилась далеко не сразу (типа pull --rebase, rebase -i со squash, pull --no-ff и т.п.).
springme
Слишком много более интересных мне вещей в которых я бы хотел разобраться на уровне «а что там происходит под капотом». Время конЕчно, во все под капот не залезешь.
А гит работает и ладно. За годы работы ни разу не возникло проблемы.
SergeyPerm
По-моему системы, где надо объединять код вручную, не совсем правильные. А также гора костылей по разделению прав доступа.
staticlab
А как вы предлагаете автоматизировать разрешение мерж-конфликтов?
humbug
Например, вот так: https://pijul.com/
staticlab
Pijul понимает конфликты и позволяет отложить их разрешение, но в конечном итоге код всё равно придётся править самому вручную.
olekl
Научиться работать с гит — научиться работать с submodules. До этого — это очень лайт версия гит :)
litwr2
Работал с ними и в нашем проекте они были скорее для создания искусственного трения между разработчиками. Без них работа получалась бы быстрее.
sav6622
Вот все равно непонятна разница в необходимости merge или rebase. Ну и что что «бриллиант» будет.
Psionic
Все пушат в мастер? Ну для небольших команд с несложной организацией пойдет. Но порой организация сложная и поэтому прежде чем попасть в сборку код должен пройти некую инспекцию, причем «под роспись» тех. специалиста что ту инспекцию проводит, в документах на такое ревью часто надо указывать имена бранча в котором работали, ну и указать что типа это можно мержить, дан апрув.
sav6622
Вот вы сейчас совсем ничего не пояснили. Даже еще больше запутали. Нужен наглядный пример чем merge отличается от rebase, лучше в картинках. А вот такое обьяснение вообще непрозрачно и куда тут rebase приложить совсем неясно.
JustDont
На пальцах: если у вас есть локальные (незапушенные) коммиты, то мердж их стандартно смерджит с коммитами в удалённом репо, и вы увидите стандартный автоматический merge-commit, равно как и diamond shape в истории коммитов. А ребейз уберет все ваши локальные коммиты, зальет код с удалённого репо, и после этого добавит ваши локальные коммиты обратно, прицепленные уже к текущему последнему коммиту из удалённого репо.
Ребейз оттого и называется ребейзом, что он перемещает «точку прикрепления» ваших локальных изменений к удалённому репозиторию.
Если надо в картинках, гляньте туториалы по гиту у atlassian, у них картинки очень хорошие:
www.atlassian.com/git/tutorials/rewriting-history/git-rebase
www.atlassian.com/git/tutorials/using-branches/git-merge
sav6622
Спасибо, чуть понятнее стало, но зачем ДВА метода решения одной задачи когда есть прекрасный merge, история которого исходит еще к временам cvs.
JustDont
Потому что всякое бывает.
habr.com/ru/post/437000/#comment_19643372
sav6622
нормальный граф, ничего страшного на мой взгляд.
Yeah
Он неюзабелен — нельзя достоверно ответить на вопрос "откуда это взялось" без пары часов изучения такого графа.
sav6622
В каком месте он неюзабелен? отлично всё видно откуда куда чего спортировали (мерджили). Да, неидеал, но вполне себе рабочий. Именно по подобным обоснованиям, я и не понимаю чем merge плох.
Yeah
Вот когда вы смерджите через пару недель самую нижнюю ветку в самую верхнюю, то я хочу посмотреть, как вы будете искать откуда взялся коммит из средней (коричневой) ветки, который заехал и туда и сюда. Плюс к этому коммит, заехавший в обе ветки с вероятностью 100% вызовет позднее конфликт, который вы будете решать на этапе позднего merge. Как показывает мой опыт как раз вот такие хаотические слияния вызывают наростающий ком конфликтов. При каждом merge при примерно полугоде разработки вы начинаете с конфликтов. При этом применяя rebase количество конфликтов сводится к минимуму, потому что сама суть rebase состоит в том, что вы приводите ветку к состоянию fast-forward, то есть ГАРАНТИРОВАННОМУ отсутствию конфликтов.
sav6622
Если делать ветку на каждое небольшое изменение и потом ее мержить и прибивать, то не вижу принципиальных радостей от rebase. А если конечно тащить две-несколько веток в параллель и портировать изменения между ними, то да, мержить будет еще то удовольствие.
Yeah
Если вы работаете в более-менее взрослом проекте, то у вас уже как минимум будет две параллельные ветки: master и develop. А если еще и gitflow применяется, так вообще еще hotfix и release добавляется.
Но даже с маленькими ветками возникает проблема: что делать, если в мастере появился новый коммит? Если вы будете мерджить ветку в мастер с решением конфликтов на месте, то у вас появляется новый неоттестированный коммит и состояние мастера автоматически становится непредсказуемым, даже если на самом деле ничего страшного не произошло.
arabesc
fshp
Ребейз как раз заменяет pull. Только у вас не будут создаваться мерж-коммиты бесполезные.
Endeavour
Звучит интересно в свете
git pull --rebase, который удобно применять при расхождении в работе над одним бранчем нескольких человек.Lissov
С мержами иногда визу по 5 мержей на пару реальных коммитов. Rebase позволит не оставлять мусор в истории. Вообще все отличия сводятся к чуть более понятной и читаемой истории, и часто вижу холивар, стоит ли оно того.
sav6622
Картинки видел, два пути, но реально когда какой использовать и в чем плюсы-минусы каждого непонятны из картинок.
Yeah
Это разные задачи. rebase нужен для приведения дочерней ветки в соответствие с родительской, а merge — для вливания изменений из дочерней ветки в родительскую. Разные отношения между ветками — вот и разные инструменты. Можно применять для всего merge, но тогда рано или поздно в более-менее активном проекте получаем merge hell
sav6622
Спасибо! Еще каплю понимания добавили для чего использовать rebase.
Ndochp
Родительская, не родительская. Это же распределенная система и все равны. Почему не смерджить мастера в фичу, а потом фичу в мастер? разве не все конфликты уйдут ровно с тем же уровнем проблем, что и при ребейзе?
Yeah
Нет, не равны. С родительской веткой работает вся команда, а с фиче-веткой — только ее часть. Потому изменения родительсткой ветки затронут большее кол-во людей и именно поэтому нужно иметь фиче-ветки как можно более готовыми к мерджу.
Конфликты уйдут, но зато добавится +1 коммит (и он не будет пустым, как при обычном merge --no-fast-forward), а потом еще +1 коммит. Если у вас мастер достаточно часто меняется, то просто за время работы над фичей в пару дней у вас может накопиться солидный ком из таких коммитов, которые по своей сути являются мусором
khim
На самом деле если у вас merge проходит «чисто» и rebase проходит «чисто», то разницы вообще никакой нету.
Разница появляется, если имеются конфликты. Интерактивный ребейз позволяет вам от них избавиться и ревьюерам на них больше не нужно будет смотреть.
Но он меняет историю, потому делать его в уже опубликованной ветке — нельзя.
Psionic
Чем мерж от ребейза отличается? Просто как дверь — при мерже изменения в ветку попадают после ее собственных изменений (коммитов), а при ребейзе они перемещаются впереди собственных изменений. Таким образом корень ветки которую ребейзят как-бы меняет корневой коммит, словно отбранчевались не от коммита 5, а скажем от коммита 8. Также ребейз может подменить корневой бранч, можно создать свой бранч от бранча А, а потом если понадобится сменить его ребейзом на бранч Б.
sav6622
Всё это безумно интересно и хорошо. НО ЗАЧЕМ? Есть мерж и всё, он есть с прошлого века. Нужны реальные рабочие примеры, чтобы понять когда его использовать, а пока и merge вполне достаточно.
OYTIS
Реальный пример №1: вы работаете над некоторой фичей в ветке. В процессе создаете еще пару веток для каких-нибудь подфич. Наконец, все готово, и вы сливаете ветки для подфич в основную ветку, чтобы затем сделать pull request в master. Если вы будете сливать свои частные ветки с помощью merge, в общей истории проекта будет видно всё ваше грязное белье, где вы бранчились, где вы мерджились и т.п. Это загрязняет историю, поэтому обычно merge используется только для того, чтобы влить вашу главную feature branch в master, тут информация о слиянии веток как раз полезна.
Реальный пример №2 (самый часто используемый сценарий использования rebase, наверное): вы снова работаете над фичей в своей ветке. Пока вы работаете, другие тоже работают, и master уходит вперед. Работа вам еще предстоит долгая, мерджится в master пока рано, но и сильно рассинхронизироваться вам не хочется. Можно было бы смерджится локально (т.е. влить master в свою ветку), но опять-таки, когда работа над фичей будет закончена, у вас в истории останутся «узелки» на всех тех местах, где вы синхронизировались. Чтобы «узелков» не было, вместо этого вы делаете rebase своей ветки относительно обновившегося master, и для стороннего наблюдателя ваш вклад будет выглядеть как линейная последовательность коммитов.
sav6622
Спасибо за отличные примеры! в принципе, картина использования rebase сформировалась, немного домыслю и начну использовать.
khim
На самом деле самый важный пример является разновидностью №2: вы разрабатываете свою фичу и выясняете, что вам чего-то не хватает. В мастере появляется новый интерфейс… а что делать вам? Вливать ваши незаконченные и неработающие разработки в мастер?
Вообще если вы считате, что «это ж история — её нужно сохранить», тогда вам лучше на Mercurial переключиться.
Подходы Git и Mecurial — строго противоположны. То есть базовая посылка одна, да, но выводы противоположны:
1. Mercurial: «история — вещь черезвычайно важная, нам нужно её не потерять — и мы сделаем всё, чтобы её сохранить».
2. Git: «история — вещь черезвычайно важная, мы не можем оставить её порождение воле случая… нам важно её грамотно написать — и для этого у нас есть инструменты!».
Так вот rebase — это один из этих инструментов. С помощью которого вы «пишите» красивую историю у вас в репозитории.
Разумеется когда история опубликована и на неё ссылаются — то менять её уже нельзя… тут Git и Mecurial сходятся во мнениях. Но вот отношение к приватной истории — разное до противоположности.
sav6622
Зачем вливать свои незаконченые и неработающие разработки в мастер? Пулить (фактически мержите) себе из мастера новый интерфейс.
По второй части — выбран git как мейнстрим, hg коллега пробовал, я — нет, сразу с svn на git.
khim
Я надеюсь вы понимаете, что с точки зрения Git'а это — та же самая операция?
У Git а ветки — не часть истории. Это временные метки, помогающие вам с историей проекта работать, не более того.
Тем не менее говорите вы как пришелец с Hg. Там, действительно, ветки являются частью репозитория и важно откуда куда вы сливаете. В случае же с Git'ом слияние — штука симметричная, а ветки, существующие в вашем локальном репозитории никак не отражаются на глобальном.
sav6622
А зачем и почему я должен это понимать? Незнание внутреннего устройства машины не запрещает большинству вполне успешно ездить по дорогам.
Я пришелец не с Hg, а с svn, которым успешно пользовался бы и дальше, если бы не загнулся assembla, точнее резко поднял цены на свой эксклюзив. Насчет веток локальный и глобальных уже догадался =)) методом наступания на грабли… зы и кстати полное копирование репозитария в git редко где описано, в большинстве источников совсем неправильно написано…
ЗЫ Подитожу так, большинство рук-в по гиту написаны явно для гиков… и как бы однобоко…
khim
Если вы не пользуетесь своим репозиторием, чтобы исправлять баги — то вам и система контроля версий не нужна. Храните бекапы на случае, если жёсткий диск умрёт — и будет вам щастя.
Не знаю. У меня есть скорее подохзрение, что они как раз написаны для «нормальных людей, которые не очень хотят знать что там внутри».
Потому что так-то можно уменьшить размер описаний раз в 10 без особой потери качества: просто описать логическую модель — всё остальное из неё автоматом следует.
develop7
hg help phases) и теперь без ключа--forceнельзя переписать только уже опубликованную историю. Впрочем, старая история экспортируется и тихонько ждёт своего часа в.hg. А если взять полуготовый плагин evolve, то и старая, и новая история будут лежать рядом и публиковаться для всех заинтересованных лиц.А в целом да, я бы тоже рекомендовал перебираться на mercurial и при необходимости поддерживать git-зеркало посредством hg-git.
khim
Я, как раз, скорее сторонник Git'а — я вообще параноик и страдаю, когда от моей работы остаются «следы» в операционке.
Но тут вопрос не что «лучше», а что «хуже» — а просто в понимании принципа. Похоже далеко не все пользователи Git'а вообще осознают что такое «ветка» и для чего они нужны.
sav6622
есть более насущные и ответственные вещи в разработке, чем ветки git. И им нужно больше уделять внимание, чем посредственному инструментарию.
develop7
khim
В современных OS мне неуютно, так как они всегда норовят запомнить обо мне больше, чем я им разрешил и ограничить их — очень тяжело.
Потому мне гораздо больше по душе Git, где я всегда контролирую — что увидят в центральном репозитории и знаю что мои способы именования веток никому не видны.
develop7
Приватные коммиты, которые никуда не уедут при пуше (вместе с именами веток/букмарок), создаются
hg commit --secret, фиксируется такое поведение выставлением параметра конфигурацииphases.new-commitвsecret. Работает это с того же 2012, то есть скоро уже 7 лет как.develop7
Так вот, если вам уж очень хочется высказаться про Mercurial, убедительно прошу перед этим ваши знания о нём обновить.
khim
Ещё раз: моя претензия к Mercurial, PowerShell и прочим подобным инструментам заключается не в том, что я не умею чистить историю или создавать секретные коммиты.
А в том, что считается, что я, по умолчанию, хочу, чтобы информация о том, что я делаю, была бы сохранена и куда-то там записана.
В Git я сам решаю какой информацией я делюсь с другими и когда. Без моих явных запросов — этого не происходит.
Как я уже сказал: разница в подходе.
P.S. Вообще я понимаю, что я — скорее исключение, чем правило. Иначе ни одна соцальная сеть бы не «взлетела». Но при этом «взлетел» почему-то Git, а не Mercurial… что немного удивляет.
sumanai
Весьма странное желание по отношению к коду. Я понимаю, когда скрывают личные данные. Сам не пользуюсь соцсетями и магазинами. Но код лучше делать публичным, он от этого лучше становится.
khim
Дык я ж не против того, чтобы публиковать код. Более того — без этого мне зарплату не заплатят.
Но я хочу контролировать: что, когда и как я публикую.
Не вижу ничего странного или неестественного в таком желании…
Lissov
Ещё один пример — вы сделали задачу в своем бранче сделанном не того бранча и надо перенести на другой. Можно без cherry-pick обойтись.
khim
Вообще git rebase — это такой «большой cherry-pick»
elmigranto
Очень условно:
Мердж берет все изменения с вливаемой ветки или веток, склеивает из в огромный патч и применяет его поверх текущего состояния.
Ребейз берет вашего общего родителями и от него проигрывает патчи из вливаемой ветки по одному, будто ветки не было и вы коммитили сразу туда, на что делаете ребейз.
sav6622
Тоже прекрасно! но в реальной работе мне это чем поможет? когда использовать один, когда другой?
fshp
Нет универсального ответа. Сколько разработчиков, столько и мнений.
Вот мое.
Для синхронизации своей ветки с мастером использую rebase. Это позволяет избавиться от промежуточных мержкоммитов.
При вливании готовой ветки (предварительно заребейзеной) в master использую merge --no-ff. Это позволяет сохранить историю и отношения коммитов.
Если ветка из одного коммита, то лучше влить ее с помощью fast forward merge.
rebase на самом деле инструмент более мощный. О позволяет не только синхронизировать ветки, но и перенести диапазон коммитов из одной ветки в другую (onto rebase), провести редактирование, удаление, переупорядочивание, слияние или разбиение коммитов (interactive rebase).
Это очень удобно, т.к. позволяет вам писать любой говнокод и не думать о коммит-сообщениях какое-то время. А затем уже можно причесать внешний вид ветки, убрать отладочные сообщения, пароли и все прочее из кода, что бы это не попало на сервер.
rustacean137
Раньше предпочитал ребейз, до одного случая...
Разработка объемной задачи была в отдельной ветки(назовем его
foo), туда сливались отдельные маленькие таски, при выполнение каждой задачи сделали ребейз с основной веткой, через неделю уже сложно былоэто сделать.
Проблема была в том, что в ветки
fooнесколько раз поменяли одны и те же файлы, а когда из основной ветки прилетал конфликты, то пришлось разрешить конфликты для каждого коммита.В первых коммитах в ветки
foo, как правило немного устаревшие версии файлов, поэтому странно разрешить конфликты с ними, когда можно сделать просто мерж и посмотреть на актуальную версию.На счет красивой истории, если не ошибаюсь, этого можно добиться используя squash commit при принятии PR.
В общем преимущество ребейс для меня сомнительна, мерж обычно справляется на отлично, мерж коммиты не мешает — их легко фильтровать.
Ребейс можно применить, например в таких случаях:
mayorovp
merge нужен для слияния долгоживущих веток.
rebase нужен для подготовки к слиянию короткоживущей ветки в долгоживущую. Подготовка нужна, чтобы убрать мусорные изменения, упростить чтение истории — ну и для разрешения конфликтов тоже.
Ещё rebase в интерактивном режиме может использоваться как инструмент для редактирования истории.
hoobastank
В проекте с 10+ разработчиков «бриллиант» превращается в огромное «макраме», в котором сложно разобрать, что произойдет при откате мержа, или какие новые фичи попали в текущий тег, например. Т.е. визуальный граф становится практически бесполезным как инструмент. Хороший пример
n00ker
а вы знакомы с git-flow? =) знаете, даже вилка превращается в кошмар, если в глаз. но это никак не характеризует вилку, а скорее того, кто её использует.
hoobastank
git-flow это «один из» возможных флоу и не является панацеей для всех.
Я отвечал на вопрос, в чем проблема мержей без рибейзов. И это — нечитаемая история.
А рибейз — единственный способ решения данной проблемы.
Git-flow, к сожалению, ее не решает, а только усугубляет:
www.endoflineblog.com/gitflow-considered-harmful
Каждый сам выбирает, что для него важней. Плюс git-а в том, что он дает возможность выбора.
Кстати, у нас в одном проекте использовался git flow (не утилита, а концепция), но при этом никто не мешал нам делать рибейзы перед мержем.
fshp
Слава гитлабу, что там можно запретить мерж, пока ветка не сможет быть смержена через ff (мержкоммит создается).
ilammy
Кстати говоря, это скриншот истории разработки самого git. Джунио вполне норм такая история, как видим.
fshp
Потому что Джунио мержит патчи пачками скриптом. Нет смысла их ребейзить.
Но вы попробуйте в рассылку отправьте набор патчей, в котором будет мержкоммит. При всей любезности Джунио и Джефа, думаю ни вас пошлют в грубой форме.
klvov
После Subversion в Git мне сложно привыкнуть к фиче, что после merge становится непонятно, на какой ветке был сделан коммит. Опция -no-ff помогает, но всё равно это идеологически отличается от того, как merge работает в Subversion. Это, наверное, не хуже и не лучше, но по-другому.
Ну и ещё то, что частично checkout репозитория не сделать, только целиком.
sav6622
Вот возможно поэтому я разницу между merge и rebase не понимаю, до этого 10 лет использовал svn.
litwr2
SVN — удобнее, а rebase в GIT штука очень полезная, рекомендую её использовать всегда и забыть про merge.
sav6622
вот опять ниочём комментарий. Большинство почему-то говорит о том что это круто, но не может пояснить в чём и почему. Я не бегу за модой, я с svn слез только полтора года назад. До этого был прекрасный монолитный репозитарий svn, накопленный за 12 лет.
Yeah
Неправильная позиция. merge нужен для вливания дочерней ветки в родительскую. Иначе получаем такой же бардак, только с другой стороны, потому что родительская ветка будет постоянно в состоянии diverged
litwr2
Извиняюсь за неточность, имел в виду, не используйте pull без --rebase. Перебазировка устаняет лишние, технические коммиты.
OYTIS
www.atlassian.com/git/tutorials/merging-vs-rebasing
Rebase — инструмент для переписывания истории коммитов, после него получается красивая линейная история изменений. Merge сливает две ветки в одну, притом обе остаются в истории. Рабочая директория в обоих случаях получается одинаковая, а лог — разный.
sumanai
Используйте Mercurial, где настоящие ветки, и информация о них не теряется ни при каких случаях.
hoobastank
По опыту, при миграции команды на git (наверное, и на другие СКВ тоже), нужно начать с документа по git-флоу на основные рабочие процессы: создание ветки для фичи, обновление ее к мастеру, мерж, решение конфликтов, перенос изменений в другую ветку и т.п.
В котором описать необходимые команды, их результат и основные сценарии ошибок. Отдельно описать best practice для вашего проекта, например почему hard reset на мастер делать не нужно, или нужно ли делать рибейз перед мержем в общую ветку.
Без опыта и четких инструкций команда новичков (особенно с доступом в мастер) может запороть мастер и подкинуть работы на пару дней более опытным товарищам.
n00ker
при миграции на гит нужно почитать документацию. чтение документации, знаете, часто помогает. и если в команде новичков есть доступ в master, то у них по определению не было более опытных товарищей. =)
hoobastank
Это не призыв к отмене чтения документации.
Коммент был скорее о том, что документация git не описывает как в данном проекте он должен быть использован. Поэтому нужно до всех донести стратегию создания и мержа веток для фич, хотфиксов и т.п.
А для особо одаренных — детально описать все пошагово.
По опыту, далеко не все сразу понимают парадигму работы с несколькими форками после SVN.
Еще одна проблема git — в нем можно одно и то же сделать по-разному. И в команде все начинают делать по-своему, что при отсутствии опыта часто приводит к проблемам.
>если в команде новичков есть доступ в master, то у них по определению не было более опытных товарищей.
В git нельзя ограничить доступ на одну ветку. Поэтому, если в проекте не используются личные форки и ограниченный доступ в основной репозиторий (что делает основные процессы намного сложней и используется далеко не везде), такой доступ будет у всех, включая новичков.
mayorovp
В популярных серверных git-решениях можно ограничить доступ на одну ветку. Так, в gitlab эта фича называется protected branches. Для пуша в защищенные ветки нужна особая привилегия, причём force push в них запрещен для всех.
Lissov
Добавлю что в TFS есть отличные Branch Policies — например коммиты только через Pull Request, с обязательными ревью и прогоном тестов, привязкой задач и т.д.
fshp
И в гитлаб все это есть.
Aingis
hoobastank
Недостаточно точно выразился. Речь не о локальном мастере, а о последующем пуше в общую рабочую ветку.
capslocky
Проблема освоения git, мне кажется, лежит именно в подобном подходе. На самом деле внутри, под капотом, git работает просто и элегантно. Но то, что снаружи — командная строка — устроено сложновато, это правда. Подобные статьи дают некоторую «графическую» интерпретацию этих внешних команд, но такой подход не отражает сути. Вот пара примеров хорошего объяснения именно на уровне логической сути тут и тут.
Londoner
Всякий раз когда мне встречается проповедник git с нездоровым блеском в глазах, я кидаю в него вот этим. Идея хорошая, а вот реализация подвела. Если нужна инструкция про то, как сделать элементарные действия, значит технология не готова к массовому использованию.
iig
git это же про программистов? С трудом представляю программиста, который способен в C++, но не способен запомнить десяток манипуляций с git.
Londoner
С++ — это ещё одни пример плохо спроектированной системы. Именно из-за своей сложности он уступил другим языкам. Так что ждём замену git.
А выучить можно что угодно. Можно, например, выучить, как отрегулировать карюбратор и перебрать подвеску в жигулях, только вот зачем, когда за те же деньги продаётся автомобиль, на котором можно просто ездить?
khim
Вы из параллельной вселенной, очевидно. Потому как в нашей впереди C/C++ только Java и Python — языки совсем другого класса, заменой C/C++ ни разу не являющиеся.
А рассказы про автомобиль никак не меняют того факта, что сегодня, сейчас — вы можете либо знать Git и работать, либо не знать — и рассказывать работодателям, почему вы решить задачу не можете… Второе, почему-то, встречает у HR меньше понимания…
Londoner
Да, Java, Scala, Python, С# и ещё десяток — языки другого класса. Но если раньше на С++ решались почти все задачи, это был универсальный язык, то сейчас только те, которые ни на одном другом языке не решаются. Ну не всем, почему-то, нравится на каждый чих писать
А HRы, точнее бизнесы, знают, что задача, требущая на С++ 10 часов работы, обычно решается на Java за пять, а на Python за два часа. Программиста на каком языке они по-вашему наймут, если это не разработка драйверов?
khim
Зависит от того, что нужно получить в результате. Я, скажем игр, без C++-движка видел почти нуль.
А там где скорость не так важна — можно и Java и Python прикрутить.
Londoner
Ну да, остались игры, драйвера, антивирусы, операционные системы. С++ настолько плох, что разработчики готовы, где можно, жертвовать быстродействием, только бы не лезть в эту трясину.
staticlab
auto же
Psionic
typedef или макросы уже не актуальны?
staticlab
Уж точно не макрос.
develop7
Симптоматично, что вы вспомнили C++: что там, что там подавляющее большинство программистов способны в ограниченное подмножество технологии, и чуть менее, чем полностью беспомощны за пределами данного подмножества.
mayorovp
Там же половина ответов неправильные...
Londoner
Тогда исправьте и опубликуйте на хабре.
feyd12
Вариант использования svn в ряде случаев совсем не устраивает?
Psionic
Да я сам дома использую svn. Но на работе у людей иное мнение, даже если фич гита не используют и все пушат в мастер.