Чуйте, я щось не зрозумів, а як "відкатитись" до необхідної версії? А-то побачив тільки як змінити останній комміт, а от як, наприклад, завантажити необхідну версію проекта?

miroslav.chandler написав:

FakiNyan написав:

Чуйте, я щось не зрозумів, а як "відкатитись" до необхідної версії? А-то побачив тільки як змінити останній комміт, а от як, наприклад, завантажити необхідну версію проекта?

Якщо в тебе є кілька версій проекту, по яким ти хочеш переключатися, тоді використовуй бранчі.

Якщо ти остаточно вирішив, шо вчорашня серія хентаю була зайвою, і під ефектом ти написав код від якого аж попахує, і ти хочеш його позбутися, юзай - git reset хеш_коміта_до_хентаю --hard, і ти опинишся на версії коміту з тим кодом який тобі потрібен.

є ше cherry-pick, але це вже совсєм другая історія

я не дивлюсь хентай, амніє - це іскусство

дякую

Ще скажу, шо всі контори, які зарах займаються девелопментом, обовязково використовують систему контролю версій - в основному git, так що вміти ним користуватися обов'язково)

miroslav.chandler написав:

Ще скажу, шо всі контори, які зарах займаються девелопментом, обовязково використовують систему контролю версій - в основному git, так що вміти ним користуватися обов'язково)

а у нас за 3 з половиною курси ніразу нічо про це не казали
і той, а якщо, наприклад, в мене є 4 проекти і у кожного своя папка, але це все один великий проект, то як мені отако це все об'єднати, щоб git працював з цим всім як з одним проектом?

bunyk написав:

FakiNyan написав:

і той, а якщо, наприклад, в мене є 4 проекти і у кожного своя папка, але це все один великий проект, то як мені отако це все об'єднати, щоб git працював з цим всім як з одним проектом?

а) Скинути всі чотири папки в одну і працювати як з одним проектом
б) Працювати як з чотирма проектами.

ну краще ж як з одним, бо якщо як з чотирма, то це ж тре 4 рази робити git init, а після нової версії одного з проектів коммітити всі інші три проекти...

FakiNyan написав:

bunyk написав:

а) Скинути всі чотири папки в одну і працювати як з одним проектом
б) Працювати як з чотирма проектами.

ну краще ж як з одним, бо якщо як з чотирма, то це ж тре 4 рази робити git init, а після нової версії одного з проектів коммітити всі інші три проекти...

азаза ж, ну.
якшо ти в двох проектах зробиш зміни, а в одному з них захочеш зробити ресет, ти розумієш, шо ти зачепиш і інший проект?

FakiNyan написав:

дивіться як вони інтегровані. Є 4 проекти. Перші два - це dll. Третій - клієнт, четвертий - сервер. Клієнт використовує dll1, сервер використовує dll1 та dll2, а dll2 використовує dll1. В dll1 - класи, котрі містять дані, в dll2 - класи, котрі містять логіку для роботи з класами описанними в dll1. Тобто, якщо я хочу щось загальне додати, то це має бути новий клас в dll1, та dll2, та новий скрипт в клієнті, а сервер не змінюється.

Тут перше треба розібратися з доцільністю структури самої системи проектів:
1. Чи є сенс виділяти дві окремі DLL, якщо одна без другої жити не може?
2. Чи можуть клієнт і сервер жити, якщо DLL будуть новіші, а клієнт самого функціоналу (скрипту) не надаватиме?

Якщо поєднати дві DLL в одну (за умови "так" на питання 2), то вийде три взаємопов'язані, але загалом незалежні проекти, які можна тримати окремо.
Як на мене - тримати окремо сервер та клієнт+спільні_DLLки не є гарно на вигляд. А все тримати в одному гіперпроекті - негнучко.

FakiNyan написав:

просто отой код в другій dll зовсім не потрібен на стороні клієнта, він відповідає лише за дії на сервері і містить необхідну інфу для сервера, типу логіна та пароля для підключення до БД

Зашити конектні дані у DLL - це по-челябінськи. А якщо ваша база раптово змінила місце прописки (сервер упав, підняли з бекапу)? Перекомпільовувати щоразу DLL?) Такі речі ліпше тримати у конфіг-файлах.