lazaryan/creative-project

Hi there 👋

My name is Sergey and I am a Front-end developer with a great desire to constantly grow as a developer and bring something new to the IT world.

My main stack is JavaScript, but I am developing in other directions as well.

• ⚡ I am writing Back-end in python, Nodejs, Rust;
• 🌱 Studied ML a little;
• 🤔 Worked with Blockchain Ethereum and wrote smart contracts for it in Solidity (and linked with services using web3);
• 🔭 Now I study computer graphics and how games work from the inside.

I am constantly developing and do not think to be satisfied with what has already been achieved ✨

creative-project's Issues

Оперирование ветками

Лучшая схема что я видел

• Есть ветка master - все что протестировано и уже в лайве
• Ветка dev - новые фичи
• Ветка по номеру задачи #номер - конкретная задача

Далее алгоритм такой

1. Появилась задача
2. Сделали новую ветку из ветки master
   git checkout origin master
   git pull origin master
   git checkout -b #номер
3. Сделали задачу
4. Проверили
5. Залили изменения в ветку
   git add файлы
   git commit -m "сделал фичу [re #номер]"
   git push origin dev
6. Сделали в github Pull request в ветку dev
7. Другой программист проверил merge request
8. Смерджили
9. Проверили в dev ветке
10. Все хорошо, повторяем тоже самое для ветки master
11. Все поломалось, откатываем изменения, ищем ошибки

Автогенерация кода

VS много вещей делает за вас, но это не причина лениться и не менять название стандартных инпутов

this->label1 и так далее такие названия почти ничего не говорят

Зачем папки с версиями?

Зачем папки с версиями?

Если как раз вся суть гитхаба, чтобы он хранил у себя все версии проекта

Названия веток

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

1. Создали в гите issue
   "написать функцию добавления поля"
2. у issue появился номер, например #3
3. создали ветку #3
4. потом ее слили

Если делать ветки по фамилиям через пару месяцев будет просто каша кода в каждой ветке. Если понадобится отключить какой-то функционал придется убить всю ветку разработчика

Группировка файлов

Файлы не плохо бы сгруппировать по папкам по их назначению

Осмысленные коммиты

Пока увидел комментарий про осмысленные коммиты.
Но осмысленных подписей к коммитам не увидел:)

добавили кода, загрузили версию это все просто слова
Какой код? что он делает?

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

Где код?

exe файлы и прочие такого рода не столь важно хранить в гите. Любой человек может скомпилировать файл локально и выполнить его.
Намного важнее хранить код

APD:

ах вот она, ветка кода)

Разделение проекта

Если проект по сути дела уже делится на предыдующую версию под тайм-кофейню и новую версию под кальянную. При этом по коду эти проекты не связаны - имеет смысл делать отдельные репозитории под каждый проект

Creative-project-TimeCoffee
Creative-project-Undegraund
Creative-project-Undegraund-Web отдельная для web версии, чтобы не путать их.
Я бы все же сосредоточился на Web версии сейчас, нежели десктопной, более перспективно разработать этот вариант. Ну а там решайте сами.