Як я можу скинути або повернути файл до певної версії?

Я вніс деякі зміни до файлу, який було здійснено кілька разів у складі групи файлів, але тепер хочу скинути / повернути зміни до нього до попередньої версії.

Я зробив git logразом з a, git diffщоб знайти потрібну мені редакцію, але просто не маю уявлення, як повернути файл до його колишнього стану в минулому.

Припустимо, що хеш потрібного вам зобов'язання c5f567:

git checkout c5f567 -- file1/to/restore file2/to/restore

Сторінка користувача git checkout надає більше інформації.

Якщо ви хочете повернутися до зобов'язань раніше c5f567, додайте ~1(де 1 - це кількість комісій, які ви хочете повернути назад, це може бути все, що завгодно):

git checkout c5f567~1 -- file1/to/restore file2/to/restore

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

Ви можете швидко переглянути зміни, внесені у файл, використовуючи команду diff:

git diff <commit hash> <filename>

Потім для повернення певного файлу до цього комітету скористайтеся командою скидання:

git reset <commit hash> <filename>

Можливо, вам доведеться використовувати цю --hardопцію, якщо у вас є місцеві модифікації.

Хорошим робочим процесом для управління шляховими точками є використання тегів для чіткого маркування точок на шкалі часу. Я не можу повністю зрозуміти ваше останнє речення, але те, що ви можете захотіти, - це розходити гілку з попереднього моменту. Для цього скористайтеся зручною командою оформлення замовлення:

git checkout <commit hash>
git checkout -b <new branch name>

Потім ви можете відновити це відносно основного рядка, коли ви готові об'єднати ці зміни:

git checkout <my branch>
git rebase master
git checkout master
git merge <my branch>

Ви можете використовувати будь-яке посилання на git-коміт, включаючи SHA-1, якщо це найбільш зручно. Справа в тому, що команда виглядає так:

git checkout [commit-ref] -- [filename]

git checkout -- foo

Це повернеться fooдо HEAD. Ви також можете:

git checkout HEAD^ foo

за одну ревізію назад і т.д.

А для повернення до останньої вчиненої версії, яка найчастіше потрібна, ви можете скористатися цією більш простою командою.

git checkout HEAD file/to/restore

У мене виникло те саме питання, і я знайшов цю відповідь найпростішою для розуміння ( commit-refє значенням SHA зміни в журналі, до якого потрібно повернутися):

git checkout [commit-ref] [filename]

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

Якщо ви знаєте, скільки комісій потрібно повернути назад, ви можете скористатися:

git checkout master~5 image.png

Це передбачає, що ви на masterгілці, а потрібна версія 5 повертається назад.

Я думаю, що я його знайшов .... від http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html

Іноді просто хочеться повернутися назад і забути про кожну зміну минулого певного моменту, бо всі вони помиляються.

Починати з:

$ git log

який показує вам список останніх комітетів та їх хеші SHA1.

Далі введіть:

$ git reset --hard SHA1_HASH

щоб відновити стан заданої фіксації та назавжди видалити всі нові зобов’язання із запису.

Це працювало для мене:

git checkout <commit hash> file

Потім введіть зміни:

git commit -a

Ви повинні бути обережними, коли говорите "відкат". Якщо у вас була одна версія файлу у фіксації $ A, а пізніше внесені дві зміни в дві окремі коміти $ B і $ C (тому ви бачите третю ітерацію файлу), і якщо ви скажете " Я хочу відкотитися до першого ", ти це справді маєш на увазі?

Якщо ви хочете позбутися змін як другої, так і третьої ітерацій, це дуже просто:

$ git checkout $A file

і тоді ви здійснюєте результат. Команда запитує "Я хочу перевірити файл із стану, записаного комітетом $ A".

З іншого боку, те, що ви мали на увазі - позбутися зміни, внесеної другою ітерацією (тобто введення $ B), при цьому зберігаючи те, що фіксація $ C зробила у файлі, ви хочете повернути $ B

$ git revert $B

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

Забавно, git checkout fooне буде працювати, якщо робоча копія знаходиться в каталозі з іменем foo; однак і те, git checkout HEAD fooі git checkout ./fooбуде:

$ pwd
/Users/aaron/Documents/work/foo
$ git checkout foo
D   foo
Already on "foo"
$ git checkout ./foo
$ git checkout HEAD foo

Ось як rebaseпрацює:

git checkout <my branch>
git rebase master
git checkout master
git merge <my branch>

Припустимо, у вас є

---o----o----o----o  master
    \---A----B       <my branch>

Перші дві команди ... зробити git checkout git rebase master

... ознайомтеся з гілкою змін, які ви хочете застосувати до masterгілки. rebaseКоманда бере коммітов з <my branch>(які не зустрічаються в master) і повторно застосовує їх до голови master. Іншими словами, батьківство першої фіксації <my branch>вже не є попереднім комітетом в masterісторії, а нинішнім керівником master. Дві команди такі ж, як:

git rebase master <my branch>

Це може бути простіше запам’ятати цю команду, оскільки і гілки «base», і «modify» явні.

. Кінцевий результат історії:

---o----o----o----o   master
                   \----A'----B'  <my branch>

Останні дві команди ...

git checkout master
git merge <my branch>

... зробіть швидке злиття вперед, щоб застосувати всі <my branch>зміни до master. Без цього кроку команда відновлення бази даних не додається master. Кінцевий результат:

---o----o----o----o----A'----B'  master, <my branch>

masterі <my branch>обидва посилання B'. Також з цього моменту безпечно видалити <my branch>посилання.

git branch -d <my branch>

Станом на git v2.23.0 є новий метод відновлення git, який повинен брати на себе частину того, що git checkoutвідповідав (навіть прийнята відповідь згадує, що git checkoutдосить заплутано). Перегляньте основні моменти змін у блозі github .

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

Отже, виходячи з відповіді Грега Х'югілла (якщо припустити, що хеш-коміт є c5f567) команда виглядатиме так:

git restore --source=c5f567 file1/to/restore file2/to/restore

Або якщо ви хочете відновити вміст одного комітету до c5f567:

git restore --source=c5f567~1 file1/to/restore file2/to/restore

Перша скидання головки для цільового файлу

git reset HEAD path_to_file

Другий замовлення цього файлу

git checkout -- path_to_file

git-псевдоніми, awk та shell-функції на допомогу!

git prevision <N> <filename>

де <N>кількість ревізій файлу для відкази файлу <filename>.
Наприклад, щоб перевірити негайну попередню редакцію одного файлу x/y/z.c, запустіть

git prevision -1 x/y/z.c

Як працює попередження git?

Додайте наступне до свого gitconfig

[alias]
        prevision = "!f() { git checkout `git log --oneline $2 |  awk -v commit="$1" 'FNR == -commit+1 {print $1}'` $2;} ;f"

Команда в основному

• виконує git logна вказаний файл і
• вибирає відповідний ідентифікатор комісії в історії файлу та
• виконує git checkoutідентифікатор комісії для вказаного файлу.

По суті, все, що можна було б зробити вручну в цій ситуації,
загорнувшись в один прекрасний, ефективний псевдонім git - git-prevision

Тут я повинен підключити EasyGit , який є обгорткою, щоб зробити git більш доступним для новачків, не плутаючи досвідчених користувачів. Одна з речей, яку вона робить, - це дати більше значенняgit revert . У цьому випадку ви просто скажете:

eg revert foo/bar foo/baz

У випадку, якщо ви хочете повернути файл до попередньої фіксації (і файл, який ви хочете відновити, вже скоєний), ви можете використовувати

git checkout HEAD^1 path/to/file

або

git checkout HEAD~1 path/to/file

Потім просто поставити і зробити "нову" версію.

Озброївшись знаннями про те, що комісія може мати двох батьків у разі злиття, ви повинні знати, що HEAD ^ 1 - перший з батьків, а HEAD ~ 1 - другий з батьків.

Або буде працювати, якщо на дереві є лише один з батьків.

Тут багато пропозицій, найбільше за змістом git checkout $revision -- $file. Кілька незрозумілих альтернатив:

git show $revision:$file > $file

А також я дуже часто використовую це для тимчасового перегляду певної версії:

git show $revision:$file

або

git show $revision:$file | vim -R -

(OBS: $fileпотрібно встановити префікс, ./якщо це відносний шлях git show $revision:$fileдо роботи)

І ще дивніше:

git archive $revision $file | tar -x0 > $file

Однак зауважте, що це git checkout ./fooі git checkout HEAD ./foo не зовсім однакова річ; випадок:

$ echo A > foo
$ git add foo
$ git commit -m 'A' foo
Created commit a1f085f: A
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ echo B >> foo
$ git add foo
$ echo C >> foo
$ cat foo
A
B
C
$ git checkout ./foo
$ cat foo
A
B
$ git checkout HEAD ./foo
$ cat foo
A

(Другий addетап ставить файл в індексі, але він не приймається.)

Git checkout ./fooозначає шлях повернення ./fooз індексу ; додавання HEADвказує Git повернути цей шлях в індексі до його HEADперегляду, перш ніж це зробити.

Для мене жодна відповідь не здавалася дійсно зрозумілою, і тому я хотів би додати мою, яка здається дуже простою.

У мене є фіксація, abc1і після цього я зробив кілька файлів (або одну модифікацію) file.txt.

Тепер скажіть, що я щось заплутав у файлі, file.txtі я хочу повернутися до попередньої версії abc1.

1 git checkout file.txt.: це видалить локальні зміни, якщо вони вам не потрібні

2. git checkout abc1 file.txt: це призведе ваш файл на необхідні версії

3 git commit -m "Restored file.txt to version abc1".: це здійснить вашу реверсію.

4. git push : це підштовхне все до віддаленого сховища

Між кроком 2 та 3, звичайно, ви можете зробити, git statusщоб зрозуміти, що відбувається. Зазвичай ви повинні побачити file.txtвже додані, і тому немає необхідності git add.

1. Git поверне файл до певної комісії

git checkout Last_Stable_commit_Number -- fileName

2.Git поверне файл до певної гілки

git checkout branchName_Which_Has_stable_Commit fileName

Щоб перейти до попередньої версії файлу файлу, отримайте номер фіксування, скажімо, тоді eb917a1

git checkout eb917a1 YourFileName

Якщо вам просто потрібно повернутися до останньої зафіксованої версії

git reset HEAD YourFileName
git checkout YourFileName

Це просто переведе вас до останнього скоєного стану файлу

git checkout ref | commitHash - filePath

напр

git checkout HEAD~5 -- foo.bar
or 
git checkout 048ee28 -- foo.bar

Багато відповідей тут стверджує, що вони використовуються git reset ... <file>або, git checkout ... <file>тим самим, ви втратите всі модифікації, <file>здійснені після виконання зобов'язання, яке ви хочете скасувати.

Якщо ви хочете відновити зміни з одного комітету лише в одному файлі, як git revertі в одному файлі (або, скажімо, підмножині файлів фіксації), я пропоную використовувати і те, git diffі git applyінше (з <sha>= хеш взяти на себе зобов’язання повернути):

git diff <sha>^ <sha> path/to/file.ext | git apply -R

По суті, він спочатку генерує патч, що відповідає змінам, які ви хочете відновити, а потім застосувати патч для зворотного скасування цих змін.

Звичайно, це не працює, якщо повернені рядки були змінені будь-яким комітом між <sha1>та HEAD(конфліктом).

Використовуйте git logдля отримання хеш-ключа для конкретної версії, а потім використовуйтеgit checkout <hashkey>

Примітка. Не забудьте ввести хеш перед останнім. Останній хеш вказує на ваше поточне положення (HEAD) і нічого не змінює.

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

cd <working copy>
git revert master

скасує останнє зобов'язання, яке, здається, робиться.

Ян

Це можна зробити в 4 етапи:

1. скасуйте всю комісію з файлом, який ви хочете спеціально відновити - це створить нову комісію для вашої гілки
2. м'яке скидання, яке виконує - видаляє фіксацію та переміщує зміни до робочої області
3. виберіть файли, щоб повернути їх і скопіювати
4. видалити всі інші файли у вашій робочій зоні

Що потрібно ввести у свій термінал :

1. git revert <commit_hash>
2. git reset HEAD~1
3. git add <file_i_want_to_revert> && git commit -m 'reverting file'
4. git checkout .

Щасти

Це дуже простий крок. Файл оформлення замовлення в потрібний ідентифікатор виконувати, тут один ідентифікатор фіксації раніше, а потім просто змінити git fix і ми закінчили.

# git checkout <previous commit_id> <file_name>
# git commit --amend

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

git revert <hash>

Поверне дану комісію. Це здається, що ви думаєте, що git revertвпливає лише на останні поступки.

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

якщо ви створюєте неправильний файл у своїх останніх зобов'язаннях, дотримуйтесь інструкцій:

1. дерево з відкритим вихідним кодом, змініть цю команду

2. змінити рядки і виявити твою фіксацію, що неправильний файл, надісланий як фіксація

3. ви можете побачити список своїх змін у цій комісії
4. виберіть його та натисніть на ... кнопки праворуч ... натисніть на зворотній файл
5. тоді ви можете побачити його на вкладці стану файлу внизу ліворуч, а потім натисніть на провал:

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