В Git ми можемо видалити будь-який проблемний файл за допомогою команди revert. Якщо ми використаємо цю команду, файл буде видалено, але версія коміту залишиться. Також буде створено нову версію коміту як частину процесу видалення файлу.
Ми можемо побачити, що файл коміту було видалено, але журнал версій коміту залишився, і також був створений новий журнал коміту для процесу видалення.
Є ще одна команда — reset. Потрібно бути дуже обережним перед використанням цієї команди. Що робить команда reset, коли ми виявляємо проблему в коміт-версії, наприклад, у версії коміту 3? У такому разі ми вибираємо коміт до версії 2. Команда reset видалить коміт версії 3.
Також, видалення всіх коміт-версій, створених після цього, означає, що буде видалено версію 3, а також скасовані коміти "Revert Bug version", і залишаться лише коміти версії 2 та версії 1, з файлом і логом Bug version. Крім того, файл буде видалено з області підготовки для коміту версії 3. Це в основному м'який скидання (soft reset). У reset є три типи — soft, — mixed, — hard.
Тепер ми розглянемо важкий скидання (hard reset). Що робить hard reset? Він також видаляє файл, тобто не зберігає його в області підготовки (staging area) та не відстежує.
Він видалить файл та лог також.
Коли ми створюємо підгілку (sub-branch), спочатку вона отримує git int від основної гілки (main), а також усі папки/файли та коміти основної гілки, і коміт основної гілки стає комітом цієї підгілки, поки ми не створимо новий коміт для підгілки. Але після першого разу, якщо ми створюємо або вносимо зміни в основну гілку, ці файли чи зміни не потрапляють автоматично в підгілку — потрібно об'єднати їх або синхронізувати. Також можна зробити таке: замість того, щоб об'єднувати всю гілку, можна вибрати конкретний коміт із підгілки та додати його в основну гілку, це називається cheery-pick.
Він вибере конкретний коміт і його файл та все з підгілки.
Щоб зберегти тимчасову роботу, ми можемо використати іншу команду git stash. Вона дозволяє тимчасово зберігати файли у staging, не даючи помилки статусу git. У реальному житті ми часто змушені залишити роботу через невідкладні справи. Так, без коміту, якщо ми залишимо файл, ми можемо його втратити. В такій ситуації ми можемо зберегти нашу роботу в stash без коміту версії.
Потім ми можемо повернутися до цього файлу, де зупинилися, і опублікувати його, або навіть видалити, якщо він не потрібен.
Після цього ми можемо перейти на головну гілку або іншу гілку та завершити наші невідкладні справи.
Після завершення невідкладної роботи ми можемо повернутися до нашої підгілки і знову почати роботу з файлом, який зберегли. Для цього спершу потрібно дізнатися, скільки файлів ми зберегли. Для цього можна використати команду git stash list.
Ми можемо побачити весь список наших збережених робіт за допомогою цієї команди.
Тепер ми відкриємо збережений файл за допомогою команди git stash pop
Тепер ми можемо працювати з цим файлом, редагувати його, навіть зробити commit (коміт). Також ми можемо видалити його назавжди. Для цього потрібно виконати команду git stash clear
Є ще одна дуже важлива команда — git squash. Використовуючи її, ми можемо об’єднати кілька версій commit (комітів) в один для підгілки. Вона об’єднає стільки commit (комітів), скільки потрібно, в один.
Однак, він автоматично не створює новий commit (коміт) для об'єднаних commit (комітів), а просто об'єднує їх і копіює файли в основну гілку. Після внесення деяких змін ми можемо просто створити новий commit (коміт) для цих файлів в основній гілці.
Тут 3 означає, скільки commit (комітів) буде об'єднано з підгілки. Останні три commit (коміти) будуть об'єднані. Вони об'єднаються з останнім commit (комітом) основної гілки, але новий commit (коміт) не буде створено. Також у цьому процесі всі файли в підгілці, які не були додані в основну гілку, будуть додані, включаючи файли трьох об'єднаних commit (комітів). Однак, якщо в підгілці є інші commit (коміти), які не були об'єднані, вони не будуть додані в основну гілку.
Ми повинні зробити звичайне злиття (merge) для них.
Отже, ми бачимо, що в підгілці ми хочемо об'єднати версії commit (комітів) (sqash file 3 та squash file 2) з останнім commit (коміт) основної гілки (merge branch “dev”), тому ми використовуємо команду git merge — — suash~2. Тож, що сталося — це те, що версія з підгілки була додана до останнього commit (коміту) основної гілки. Також ми бачимо, що всі файли з підгілки були скопійовані в основну гілку, навіть ті файли, які не належать до squash commit (комітів).
Тепер, якщо ми хочемо зберегти/задекларувати ці файли в основній гілці, ми можемо це зробити, створивши новий commit (коміт).
Ми бачимо, що наш squash (сгладжування) спрацював, оскільки всі файли з підгілки були скопійовані, але в підгілці залишилось ще багато commit (комітів). Якщо ми злиємо (merge) з основною гілкою за допомогою команди git merge branch-name, ми отримаємо всі інші commit (коміти) також, але ці commit (коміти) будуть відображені окремо, як у підгілці. Однак файли залишатимуться такими ж, оскільки вони вже були скопійовані. Git squash (сгладжування) головним чином працює ефективно для файлів. Для кращого відслідковування ми будемо використовувати докладні commit (коміти) під час створення нової версії.
Є ще одна важлива річ — це вирішення проблеми з конфліктами злиття (merge conflict). Іноді ми отримуємо файл з однаковим ім'ям з різних підгілок. Навіть якщо їхній вміст різний, ім'я файлу зберігається. Тому ми можемо відредагувати ці файли і вибрати, який вміст файлу залишити, а який видалити.
Також ми можемо зберегти обидва файли.
Тепер ми відредагуємо файл і збережемо його, створивши новий commit (коміт) для цієї версії.
Перекладено з: Learning Git & GitHub Advanced Topics