Как вы используете git при разработке в одиночку?

Question

[Станислав Фатеев]

Работаю как фрилансер, проекты небольшие и все их я веду один, без команды.

Пытался использовать методику Git Flow для работы. Вначале все хорошо, создаются ветки для фич, маленькие коммиты с осмысленным описанием, мерджи. Но в итоге, в процессе творчества все это надоедает и скатывается к коммитам сразу в master из десятка файлов с несколькими фичами и описанием вида "big update".

Как вы с этим справляетесь? И вообще нужен ли здесь Git Flow или забить на все и работать как работается?

Answer 1

[Adamos]

Для себя одного git, как мне кажется, нужен только как "машина времени" и "обратный роадмап".
То есть, чтобы иметь возможность посмотреть более ранний вариант кода и чтобы в потоке коммитов найти, когда были какие-то конкретные изменения.
По большому счету, ничего, кроме коммитов в мастер, тут и не требуется. Разве что желательны мелкие коммиты с осмысленным написанием изменений, а не куски того, о чем сам не вспомнишь через неделю.

Comments

[evnuh]

Вы почитайте про Git Flow, GitHub Flow, подумайте, кто их придумал и зачем. Даже если ты работаешь один, фичи и баги появляются неравномерно, непоследовательно, и иногда приходится работать сразу над 2-3 тасками, как вы будете переключаться между ними, коммитя всё в мастер?

[Adamos]

evnuh: мне, как правило, вполне удается работать именно последовательно. Именно с этой колокольни и рассуждение.
Да, если ведется несколько параллельных разработок, потребуются ветки. О чем тут спорить?

[evnuh]

Adamos: автор вопроса не понимает зачем нужен git flow, а вы ему дакаете, что только усугубляет ситуацию.

[Adamos]

evnuh: а вы не верите в реальность ситуации, при которой автору совершенно не впился git flow, поскольку разработка не требует ответвлений? Я описал именно такую ситуацию, подходит она автору или нет - наверное, ему виднее...

[evnuh]

Adamos: Вначале все хорошо, создаются ветки для фич, маленькие коммиты с осмысленным описанием, мерджи. Но в итоге, в процессе творчества все это надоедает и скатывается к коммитам сразу в master из десятка файлов с несколькими фичами и описанием вида "big update".

У человека были фичи, были ветки под них, а превратилось всё в "big update", из которого уже ничего не откатить. И ему-то не впился git flow?

[Adamos]

evnuh: да, вполне возможно, что ветки он создавал только потому, что прочитал, что так делают все крутые пацаны. Пользы от них так и не случилось, забросил - в результате с водой выплеснут и младенец (маленькие коммиты с осмысленным описанием).

Answer 2

[WebDev]

Ну я думаю, что не стоит рассказывать о прелестях и возможностях гита. Если вы работаете в одиночку, то не обязательно использовать ветки. Можно и в мастер коммитить, и использовать для того, чтоб всегда можно было откатиться к любой версии. Я тоже, когда работаю над небольшими проектами в одиночку не пользуюсь ветками. Но если проект "живой", и весит в вебе, то всегда есть риск, что что-нибудь сломается, и тогда, чтоб в попыхах не ломать голову, пытаясь найти ошибку, и не наломать дров, как обычно и бывает, когда срочно нужно что то поправить, можно спокойно откатиться до рабочей версии и искать неспеша ошибку. Хотя бы ради этого стоит использовать гит.

Comments

[God Emperor]

Не согласен. Ветки всё равно нужны.

[WebDev]

Если они только мешают и путают - то нет

[Viktor Koltcov]

kirill-93: это скорее признак того что у них не правильные имена/организация. Разве нет?

[WebDev]

Viktor Koltcov Я вот не люблю, когда человеку навязывают какие то инструменты, и говорят, что если он ими не пользуется, то он неправильно живет. Если у меня простой проект, зачем на мне на каждый чих создавать ветку? Автор вопроса пишет, что проекты у него простые, и вообще он сомневается, нужен ли ему гит. Значит он и без него обходится прекрасно.

[Viktor Koltcov]

kirill-93: никто не навязывает, это только мое мнение. Я хотел донести мысль, что если вы создаете ветки и они вам мешают, то вместо того чтобы от них полностью отказаться лучше подумать как их организовать иначе чтобы они помогали.

[Дмитрий Вапельник]

kirill-93: даже если проект маленький, то я делаю ветку master, в которую периодически вливаю через merge commit ветку dev, в которую по фичам вливаю через merge commit ветки отдельных фич или этапов разработки. при этом делаю себе мелкие таски, чтобы не потеряться в потоке разработки и случайно не начать фиксить багу, которая не касается текущего таска. найденную багу записываю в note чтобы вернуться к ней когда закрою текущую таску.
если не хватает самоорганизации и пишете проект одним потоком мысли, то от big commits тоже не будет никакого толку ибо откатываться придется непонятно куда. в итоге от контроля версий тоже никакого толку - не используйте git и Git Flow вообще

Answer 3

[Алексей Кулаков]

Конечно сложно себя дисциплинировать. Но когда вырабатывается привычка, то стараешься писать осмысленные комментарии к комитам. Особенно когда нужно что-то найти в десятке тысяч комитов, тытаешься делать так чтобы было понятно по описанию комита. Иначе придется постоянно копаться в самих изменениях комитов, чтобы найти то, что нужно. По сути, в пределах отдельной ветки которая названа более-менее нормально (а мы стараемся делать именно так, ветка на каждый task или issue и по завершению закрывать и сливать с основной) можно и писать менее осмысленные комментарии.

Нужно себя пересиливать, выдавать себе люлей раз начальника нет хотябы полгодика, типа "какого х.. тут ты понаписал этот бред!? ни..я ведь не понятно что да как в этом комите!". Потом втянитесь и скилл наработаете. Мне было лениво писать хорошие комменты комитов, когда английский был не очень (все только на нем, даже в коде описания и комментарии только на нем), сложно было попросту. А сейчас подтянул, словарный запас поднатаскал, скилл наработал и проще сформировать мысли при комите.

В общем будьте самокритичнее и требовательнее к себе. Или вы, извиняюсь, настолько тряпка что не можете дать себе "бодрящего пенделя" когда это надо?

Comments

[AlexanderG]

>ветка на каждый task или issue
Расскажите подробнее, пожалуйста. Никак не могу определиться с именованием feature-веток: можно просто делать их как issues/, а можно называть более осмысленно по имени фичи (feature/). Кажется, что первый вариант более унифицирован, но второй нагляднее — сразу понятно, о чем ветка, не нужно ходить в трекер задач. Как быть?

[sudo rm -rf /]

AlexanderG, а что мешает совмещать? Например, что-то вроде issues[-feature]/ Приоритетом здесь, на мой взгляд, является issues, так как несет в себе исчерпывающую информацию. А осмысленное описание можно сделать, если получается более-менее компактно описать фичу. Если нет, то будет только мешать, имхо, а значит и нафиг не нужно.

Answer 4

[Денис Инешин]

Пока вы ведете проекты в гит только для себя, никогда вы не сможете внедрить гит флоу нормально.

Это пойдет в тот момент, когда вы будете разрабатывать какие-нибудь большие продукты, например Open Source, где важно соблюдать версии, писать четкие описание изменений и т.д. Ну или поработать в команде, так чтобы это засело в подкорку.

Answer 5

[Роман Франк]

Постоянно использую, комичу все изменения по разным задачам по проекту, пишу осмысленный комментарий, не испытываю проблем. Это уже как привычка.

Answer 6

[Alex XYZ]

Работаю хоть и в большой фирме, но сказал бы, что почти в одиночку, но если бы не ветки с мерджами, было бы труднее. В какой-то момент перестало хватать только git и я вокруг git построил небольшую инфраструктуру:

- Поставил на работе gitlab, загрузил с github несколько значимых, проектов, потому что некоторые были с ошибками, исправил те ошибки, теперь можно скачивать с github новые версии и применять свои исправления
- незаметно количество проектов выросло почти до 70 штук и похоже, что будет расти дальше. Часть из них - эксперименты с подробной документацией. На работе иногда перекидывают на разные работы, документация позволяет контекст вспомнить
- веду лайфлог в zim wiki desktop и на свой gitlab периодически выкладываю.
- стараюсь популяризовать git среди своих коллег.

Вывод - пренебрегать flow не стоит. Неизвестно, когда потребуется вернуться назад и к этому надо быть готовому (немного популистски, но близко к реальности).

Answer 7

[Viktor Koltcov]

1) Коммитить чаще, тогда проще придумать что написать в комментарии, а чтобы проще разобраться в этих мелких коммитах объединять их в ветках.

2) Не забывать для чего вы используете git:
- знать когда что и зачем исправил в коде
- иметь возможность переключится на состояние кода на момент релиз и сделать hotfix
- ... ?
Если будете помнить зачем вам git автоматически будете делать коммиты и организовывать ветки правильно.

Answer 8

[abcd0x00]

Использую git по принципу master/devel. В master идут только крупные изменения вроде новых версий, которые помечаются тегами. В devel идут только принимаемые изменения (никаких ошибок). Для каждого нового процесса создаётся ветвь, которая вливается в devel, когда полностью завершена. А вот ветвь процесса может быть одна или ветвиться дальше.

Зачем это нужно? Проектов много, каждому по несколько лет уже. Когда через год открываешь что-то, то не очень помнишь, какие там были нюансы, задумки. У меня бывало уже такое, что я открывал собственный код и никак не мог даже вспомнить, когда это я его писал.

Comments

[Adamos]

"никак не мог даже вспомнить, когда это я его писал" - это семечки.
Обычно не можешь вспомнить, зачем это писалось и почему именно так.
Острый случай - не можешь вспомнить, что это такое вообще, но надо срочно внести небольшую правочку ;)

Answer 9

[Артемий Зайцев]

Хороший вопрос! В нашей веб-студии все сайты делаются одним разработчиком. И почти всегда на продакшене. Потому что сайт - это сайт. Клиент тыкает пальчиком и хочет фичу - сделал, показал, уточнил, переделал. И пусть меня закидают камнями, но в большинстве проектов система контроля версий не нужна. Нужны обычные резервные копии.

Однако:

Копирование кода в репозиторий позволяет:
- иметь резервную копию, если клиент, вирус, или кто-то что-то сломает. Далаешь коммит и видишь что поменялось.
- ядро CMS обновляется, иногда история коммитов позволяет найти, что ошибка возникла из-за обновления какого-то файла. Раньше было так, а теперь так.

Есть проекты, когда нельзя вести разработку на продакшене. Например, тестируем выгрузку каталога товаров из 1С. Тогда удобно делать две копии продукта: дев и продакшен. Делать разработку на деве и отправлять изменения на продакшен.

У себя мы используем mercurial. Но в гит логика аналогичная.

Answer 10

[Пума Тайланд]

Просто коммичу любые значимые изменения с вменяемым небольшим комментом

Answer 11

[ummahusla]

Стараюсь использовать гит, без gitflow, иногда хорошо самому себе спасает жопу, когда наговнокодил и нужно ресторнуть предыдущую версию.

Answer 12

[zjoin]

Я для разработки использую ветку dev. И к конце каждого дня делаю коммиты в ветку master.

Answer 13

[tvolf]

Нашел одну веселую картинку на тему умения правильно давать названия коммитам ) В свое время очень она меня порадовала )

Answer 14

[trevoga_su]

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

Comments

[Adamos]

Версионность не нужна для веб-сервисов, которые всегда актуальны, и для узких приложений с десятком пользователей, которых не проблема постоянно обновлять до свежей версии.
С самостоятельной программой, у которой тысячи пользователей, версионность остро необходима - в первую очередь автору. Потому что решение большинства запросов в техподдержку в первую очередь зависит от того, какая у пользователя версия программы.