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.