Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → Системи контролю версій (SCM, VCS) → Ґітгаб, як зробити коміт в одну гілку, і замерджити в іншу з термінала
Сторінки 1
Для відправлення відповіді ви повинні увійти або зареєструватися
Хай. В мене є дві гілки - develop та master. Зараз я роблю коміти в develop (в терміналі), а потім йду на сам github, роблю pull request з develop в master, і мерджу.
Як мені зробити останню операцію сидячи в себе в терміналі, і не переходячи на сам сайтик github'а?
ну ок, в слід. раз спробую
фігня то все, воно не дає пушити в мастер, каже - спочатку зтягни, але якщо я зтягну, то воно ж затре те, що вийшло після
git merge develop?
щось я не наздоганяю, як те rebase зробе, що мені тре, якщо воно дозволяє змінювати історію комітів і все таке
А як хочеш пострадати то є ще git log i git cherry-pick
та я черіпікав ще задовго до створення цієї теми, просто то я все робив на якомусь сайті по вивченню Ґіту, і давно, то вже й забув
okay, що я роблю - зробив новий коміт на develop
тепер переходжу на master і роблю git pull
потім роблю gut rebase develop і дивлюсь, що буде
наче ніяких помилок, тепер роблю git push origin master
а от запушити не вийшло, пише що треба git pull знову, після чого каже - Already up-to-date! Merge made by the 'recursive' strategy
і тепер вже запушилось
Ліпше rebase: безпечніше (у мерж-конфліктах) і послідовніше буде, а суть, загалом, та сама.
В правилах української не встигли додати що між словами "rebase" і "безпечніше" обов'язково пишеться "не".
http://www.benjaminfleischer.com/2010/1 … -torvalds/
https://habrahabr.ru/post/179123/
https://habrahabr.ru/post/179673/
А я от навпаки мердж-коміти не люблю, і тільки ребейзом і користуюсь
Певно такі проблеми з’являються після якогось числа програмістів на один репозиторій
Блін. Факі не роби такого. Тебе за таке на фірмі бити будуть. Ребейс девелопменту роблять на основі мастера, а не мастера на основі девелопменту. Воно звичайно чисто фізично можна таке робити, але при цьому ти повністю ігноруєш логіку по якій створювались системи контролю версій.
Блін. Факі не роби такого. Тебе за таке на фірмі бити будуть. Ребейс девелопменту роблять на основі мастера, а не мастера на основі девелопменту. Воно звичайно чисто фізично можна таке робити, але при цьому ти повністю ігноруєш логіку по якій створювались системи контролю версій.
не пойняв, що не так?
треба було спочатку git rebase develop - це я змінюю master використовуючи коміти з develop? а треба як?
спочатку git pull на master, потім перейти на develop і git rebase master, а потім що?
Vo_Vik написав:Блін. Факі не роби такого. Тебе за таке на фірмі бити будуть. Ребейс девелопменту роблять на основі мастера, а не мастера на основі девелопменту. Воно звичайно чисто фізично можна таке робити, але при цьому ти повністю ігноруєш логіку по якій створювались системи контролю версій.
не пойняв, що не так?
треба було спочатку git rebase develop - це я змінюю master використовуючи коміти з develop? а треба як?
спочатку git pull на master, потім перейти на develop і git rebase master, а потім що?
А потім checkout master і merge developer
Сторінки 1
Для відправлення відповіді ви повинні увійти або зареєструватися