Git створити гілку з поточного перевіреного майстра?


78

На сервері є папка, керована git, де головна гілка відмічена, і ціла купа файлів була змінена і не фіксується. Чи є спосіб для мене внести зміни в окрему гілку, щоб я міг повернутися до чистої версії?

тобто я хочу ефективно скасувати всі ці зміни людей, але зберегти їх в іншому шансі, щоб, якщо ця особа хоче їх змін, вони могли перейти на цю гілку.

(Так, я знаю, що так працює не git, але це моя ситуація!) Будь-які ідеї дуже оцінені.


1
схожий на < stackoverflow.com/questions/1394797/… >. і привіт, git дуже добре працює у вашому випадку, я б не сказав, що він не призначений для такого робочого процесу. Це є!
— knittl

Тільки для роз’яснень, я сподіваюся, що зміни ніколи не будуть використані, але мені потрібен постійний запис про всяк випадок.
— corydoras

Відповіді:


136

Перш за все перехід до іншої гілки, що базується на поточній HEAD, виконується так:

git checkout -b newbranch

Зафіксувати всі зміни (припускаючи відсутність нещодавно доданих файлів, інакше git addїх):

git commit -a

Поверніться до головної гілки:

git checkout master

Раніше нездійснені зміни будуть усі в новій гілці філії, а майстер все ще буде в такому стані, як було без цих змін.


5
Пояснення: вміст робочого сховища та поетапні зміни не належать до жодної гілки. Простого створення нової гілки з HEAD (остання редакція) достатньо, щоб новий коміт продовжив щойно створену гілку <newbranch>.
— Якуб Нарембський

Дякую, хлопці, я думав, що перехід на нову гілку може знищити зміни. Виходячи з фона SVN, я не думав, що таке переключення можливо. Тестуємо це зараз.
— corydoras

14

Цей метод корисний:

git checkout -B <new_branch> <start point>

Де:

  • <new_branch>це ваша нова гілка (наприклад my_branch)
  • <start point>це ваша початкова гілка ( masterу вашому випадку)
  • -Bстворює нову гілку, починаючи з <start point>, якщо вона вже існує, а потім скиньте її до (вона не провалиться, як -bколи гілка вже існує)
  • іноді -mможе бути корисно вказати при перемиканні гілок, це буде виконувати тристороннє злиття між поточною гілкою та вмістом вашого робочого дерева (корисно для сценаріїв).

Детальніше man git-checkoutдив.


13

Ви завжди можете приховати свої зміни.

git stash
git checkout -b bravenewmaster
git stash apply

Також майте на увазі, що якщо ви здійсните фіксацію в "неправильній" гілці, ви завжди можете перемістити цю гілку назад, оскільки гілка - це не що інше, як вказівник на коміт.


3
Навіщо турбуватися про сховання, якщо ви збираєтеся негайно повторно застосувати ті самі зміни? Ви можете просто зробити git checkout -b bravenewmaster. Це менше набору тексту і не торкається всіх змінених файлів без потреби.
— CB Bailey

1
Ну, я не пробував, але я припускав, що gitз будь-якої причини не дозволяє, git checkout -bколи є зміни. Інакше, навіщо запитувати? ;-)
— Майкл Крелін - хакер

Власне, щодо того, що я можу сказати, сказавши: "Я хочу ефективно скасувати всі ці зміни людей, але зберегти їх в іншому шансі, щоб, якщо ця людина хоче їх змін, вони могли переключитися на цю гілку", зауваження - одне сховання повинно бути достатнім без розгалуження та застосування .
— Майкл Крелін - хакер

1
Якщо він зберігає зміни (а не тимчасово зберігає), то, мабуть, доцільніше мати коміт (із повідомленням) на названій гілці, ніж схованку, яку не слід випадково скинути. Проте обидва спрацювали б.
— CB Bailey

1
Звичайно, я не можу повністю зрозуміти наміри інших людей, але у мене склалося відчуття, що "я хочу працювати над цим екземпляром, але ти все це змінив, ти міг би обійти стороною і розібратися з цим сам пізніше" ;-)
— Майкл Крелін - хакер
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.