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

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

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

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

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

То есть, чтобы иметь возможность посмотреть более ранний вариант кода и чтобы в потоке коммитов найти, когда были какие-то конкретные изменения.  

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

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

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

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

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

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

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

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

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

- Поставил на работе gitlab, загрузил с github несколько значимых, проектов, потому что некоторые были с ошибками, исправил те ошибки, теперь можно скачивать с github новые версии и применять свои исправления  

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

- веду лайфлог в zim wiki desktop и на свой gitlab периодически выкладываю.   

- стараюсь популяризовать git среди своих коллег.  
  

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

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

2) Не забывать для чего вы используете git:  

- знать когда что и зачем исправил в коде  

- иметь возможность переключится на состояние кода на момент релиз и сделать hotfix  

- ... ?  

Если будете помнить зачем вам git автоматически будете делать коммиты и организовывать ветки правильно. 

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

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

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

Однако:  
  

Копирование кода в репозиторий позволяет:  

- иметь резервную копию, если клиент, вирус, или кто-то что-то сломает. Далаешь коммит и видишь что поменялось.  

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

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

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

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

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

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

 Нашел одну веселую картинку на тему умения правильно давать названия коммитам ) В свое время очень она меня порадовала )  
![hhGnpOF.jpg](https://habrastorage.org/files/4b2/71d/6cf/4b271d6cfd6942b099719a26cf1c7807.jpg) 

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

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