що таке еквівалент Git команд TFS для відключення / відключення? вишенька?


76

Я виявив, що команди police / unshelve у TFS дуже зручні та дуже прості у використанні. Що еквівалентно в Git?

ось сценарій у TFS:

  • Я вніс зміни в багажник
  • Я зберігаю: набір змін зберігається на сервері (з міткою), і я отримую джерело назад перед змінами
  • Я працюю в багажнику
  • Хтось може відмовитись: отримати зміни, встановлені у його робочій області

Я знаю, що існує виклик команди cherry-pick, але я не впевнений у робочому процесі та в тому, чи це відповідає потребі.

Відповіді:


85

Те, що ви описуєте, схоже git stash, за винятком того, що у git у вас є власне сховище (а не лише одне на сервері), лише ви можете повернути цю зміну назад.

Загальна ідея така:

# do some stuff
vim foo/bar.c
# stash away your changes
git stash

# do some other things...

# retrieve your changes
git stash pop

Якщо ви хотіли, щоб хтось інший мав доступ до цього набору змін, ви хотіли б замість цього закріпити його за робочою гілкою:

# make yourself a branch
git checkout -b temp-featureA
# commit to it
git add foo/bar.c; git commit

# now you push this branch (or they could just fetch straight from you)
git push origin temp-featureA


# Now, in someone else's repo:
# Fetch updates
git fetch origin
# Make a branch tracking the remote branch
git branch temp-featureA origin/temp-featureA

# Either check it out:
git checkout temp-featureA
# or cherry-pick it, to apply the changes somewhere else:
git cherry-pick temp-featureA
# or, if it's multiple commits, rebase it!
git rebase --onto my-branch start-of-featureA temp-featureA

Будь-яка ідея, що робити, якщо я не хочу вносити ці зміни на набір стелажів? У нас є рядки зв’язків, які ми змінюємо, щоб потрапити в різні середовища, але ми не хочемо змінювати їх на master, лише для локальної налагодження, якщо вони є у гілці, вони будуть зафіксовані при натисканні, якщо ми об’єднаємо їх у нашу гілку
Mech0z

Чи є спосіб сховати, зберігаючи місцеві зміни? Чи може бути схованка, за якою застосовується схованка?
Psddp

Так, stash then stash apply по суті зробив би це. Але я трохи розгублений, чому ти цього хочеш. Як правило, якщо ви ховаєте, це тому, що ви хочете, щоб зміни тимчасово зникли, і ви повернете їх кудись ще. Якщо ви збираєтеся тримати їх поруч і продовжувати працювати, можливо, вам буде краще просто взяти на себе зобов’язання. Потім ви можете вибирати вишні, які виконують в іншому місці, замість того, щоб застосовувати схованку, і ви завжди можете придушити її згодом, якщо хочете прибрати.
Cascabel

3
Насправді це насправді не те саме, що TFS Shelveset. Якщо я працюю над локальною гіткою git ... наприкінці дня я хочу сказати ... з усіма бородавками та помилками компіляції .... покладіть цю роботу на сервер для безпечного зберігання. Отже, якщо мій жорсткий диск виходить з ладу, я не втрачаю все. Однак я ще не хочу підштовхувати свою роботу до віддаленої гілки, оскільки вона є неповною. Моє місцеве відділення відстежує віддалене відділення. Cascabel перераховує 8 окремих команд git, щоб організувати це ... в TFS ... це одна команда ... Полка.
Байрат

29

Те, що ви хочете зробити, досягається за допомогою простого старого розгалуження в git.

З приємної відповіді StackOverflow від JaredPar :

Стелажі - це спосіб збереження всіх змін у вашому ящику без реєстрації. Зміни зберігаються на сервері.

Це аналогічно фіксації для гілки та надсилання її на сервер у git.

Як це зробити:

Скажімо, ви працюєте над гілкою "master" і вирішили застосувати функцію X. Ви добре її розпочали, але тоді ваш начальник повідомляє, що функцію Y потрібно впровадити якомога швидше. Філ у наступному кубі над добровольцями, щоб закінчити функцію X, поки ви робите Y. Ось що ви робите:

Створіть нову гілку та перейдіть до неї:

$ git checkout -b feature-x

Зафіксуйте свої зміни:

$ git add filethatyouchanged.cc
$ git commit -m 'partial implementation of feature X'

Надішліть його на сервер, який Філ бачить:

$ git push origin feature-x

Поверніться до головної гілки (яка не змінилася):

$ git checkout master

Ви також можете заздалегідь створити нову гілку для функції Y:

$ git checkout -b feature-y

Тепер Філ може зняти вашу функцію X і продовжити там, де ви зупинилися:

phil$ git fetch origin
phil$ git checkout -t origin/feature-x

2
хоч і не такий дешевий, як у git, він насправді зберігається в репо, і якщо репо розподіляється, це означає, що ви можете подати свою полицю на будь-який комп'ютер із репо, не перетворюючись на коміт. (TFS2010) Це дуже зручно, якщо існує якась політика, як-от CI або Gated Check-In (обов'язкова збірка на стороні сервера при кожному реєстрації)
Onno,

5

git stash трохи схожий, за винятком того, що він обмежений вашим робочим деревом.

У DVCS, щоб досягти такого робочого процесу, вам потрібно:

  • зафіксуйте поточні зміни в новій гілці
  • перевірте оригінальну гілку, куди можна продовжувати, без жодних змін, які ви ввели (але здійснили в новій гілці)
  • натисніть цю нову гілку на оголене репо
  • дозволити іншому розробнику витягнути цю нову гілку та об’єднати її зі своєю поточною гілкою.

Іншим способом було б дозволити іншому розробнику забрати вашу гілку (де ви здійснили цей спеціальний набір змін) і вибирати її , але це не рекомендується, оскільки вибрані вишневі коміти важко відстежити .


Дякую за вашу відповідь, я позначив відповідь Джефромі, оскільки вона дає мені приклад, але ваша також допомогла.
MatthieuGD
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.