svfat
@svfat
☺Нужен VPS? Два месяца бесплатно. Смотри профиль☺

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

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

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

Как вы с этим справляетесь? И вообще нужен ли здесь Git Flow или забить на все и работать как работается?
  • Вопрос задан
  • 7411 просмотров
Решения вопроса 9
Adamos
@Adamos
Для себя одного git, как мне кажется, нужен только как "машина времени" и "обратный роадмап".
То есть, чтобы иметь возможность посмотреть более ранний вариант кода и чтобы в потоке коммитов найти, когда были какие-то конкретные изменения.
По большому счету, ничего, кроме коммитов в мастер, тут и не требуется. Разве что желательны мелкие коммиты с осмысленным написанием изменений, а не куски того, о чем сам не вспомнишь через неделю.
Ответ написан
@kirill-93
Ну я думаю, что не стоит рассказывать о прелестях и возможностях гита. Если вы работаете в одиночку, то не обязательно использовать ветки. Можно и в мастер коммитить, и использовать для того, чтоб всегда можно было откатиться к любой версии. Я тоже, когда работаю над небольшими проектами в одиночку не пользуюсь ветками. Но если проект "живой", и весит в вебе, то всегда есть риск, что что-нибудь сломается, и тогда, чтоб в попыхах не ломать голову, пытаясь найти ошибку, и не наломать дров, как обычно и бывает, когда срочно нужно что то поправить, можно спокойно откатиться до рабочей версии и искать неспеша ошибку. Хотя бы ради этого стоит использовать гит.
Ответ написан
@carbon88
.NET developer/ORM developer
Конечно сложно себя дисциплинировать. Но когда вырабатывается привычка, то стараешься писать осмысленные комментарии к комитам. Особенно когда нужно что-то найти в десятке тысяч комитов, тытаешься делать так чтобы было понятно по описанию комита. Иначе придется постоянно копаться в самих изменениях комитов, чтобы найти то, что нужно. По сути, в пределах отдельной ветки которая названа более-менее нормально (а мы стараемся делать именно так, ветка на каждый task или issue и по завершению закрывать и сливать с основной) можно и писать менее осмысленные комментарии.

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

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

Это пойдет в тот момент, когда вы будете разрабатывать какие-нибудь большие продукты, например Open Source, где важно соблюдать версии, писать четкие описание изменений и т.д. Ну или поработать в команде, так чтобы это засело в подкорку.
Ответ написан
@Akellacom
CTO
Постоянно использую, комичу все изменения по разным задачам по проекту, пишу осмысленный комментарий, не испытываю проблем. Это уже как привычка.
Ответ написан
AlexZaharow
@AlexZaharow
Программист. Javascript, Java!
Работаю хоть и в большой фирме, но сказал бы, что почти в одиночку, но если бы не ветки с мерджами, было бы труднее. В какой-то момент перестало хватать только git и я вокруг git построил небольшую инфраструктуру:

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

Вывод - пренебрегать flow не стоит. Неизвестно, когда потребуется вернуться назад и к этому надо быть готовому (немного популистски, но близко к реальности).
Ответ написан
Vityarik
@Vityarik
1) Коммитить чаще, тогда проще придумать что написать в комментарии, а чтобы проще разобраться в этих мелких коммитах объединять их в ветках.

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

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

Однако:

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

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

У себя мы используем mercurial. Но в гит логика аналогичная.
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
opium
@opium
Просто люблю качественно работать
Просто коммичу любые значимые изменения с вменяемым небольшим комментом
Ответ написан
Antonoff
@Antonoff
Разработчик
Стараюсь использовать гит, без gitflow, иногда хорошо самому себе спасает жопу, когда наговнокодил и нужно ресторнуть предыдущую версию.
Ответ написан
@zjoin
Я для разработки использую ветку dev. И к конце каждого дня делаю коммиты в ветку master.
Ответ написан
tvolf
@tvolf
Нашел одну веселую картинку на тему умения правильно давать названия коммитам ) В свое время очень она меня порадовала )
hhGnpOF.jpg
Ответ написан
trevoga_su
@trevoga_su
использую svn чисто как удаленное хранилище, что бы из любой точки можно взять код и начать его дописывать.
версионность вообще не нужна, когда один работаешь. даже ни разу не было потребности смотреть в историю.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы