programing

Git에 단계별 변경 사항만 저장하려면 어떻게 해야 합니까?

closeapi 2023. 5. 16. 22:40
반응형

Git에 단계별 변경 사항만 저장하려면 어떻게 해야 합니까?

제가 준비한 변경 사항만 보관할 수 있는 방법이 있습니까?문제가 되는 시나리오는 한 번에 여러 버그를 처리하고 몇 가지 단계별 변경 사항이 있을 때입니다.이 파일들을 개별적으로 스테이징하고, .patch 파일을 만들고, 코드가 승인될 때까지 저장할 수 있었으면 합니다.이렇게 하면 승인되면 전체 (현재) 세션을 저장하고 버그를 제거한 후 코드를 푸시할 수 있습니다.

제가 잘못된 길로 가고 있는 건가요?GIT가 프로세스를 단순화하기 위해 다른 방식으로 작동할 수 있는 방법을 오해하고 있는 것입니까?

네, 더블스택으로 가능합니다.

  1. 저장해야 하는 모든 파일을 준비합니다.
  2. 려달을 합니다.git stash --keep-index이 명령을 실행하면 모든 변경 사항(단계별단계별)이 포함된 스택이 생성되지만 작업 디렉토리에서 준비된 변경 사항은 그대로 유지됩니다(상태 준비 상태).
  3. 려달을 합니다.git stash push -m "good stash"((으)를 -u stash를 지정합니다.
  4. 이제 당신의"good stash"준비된 파일만 있습니다.

이제 스테이징되지 않은 파일이 스테이징되기 전에 필요한 경우 먼저 스테이징된 파일(로 생성된 파일)을 적용하면 이제 스테이징된 파일을 제거할 수 있습니다."good stash".

즐거운 시간 되세요.

git stash push -S

명령에 별칭을 .git config --global alias.stashs 'stash push -S'.

여기에서 방법을 찾을 수 있습니다.stash only unstaged변화들.

OLD
git stash push --staged2시 35분 이후

현재 준비된 변경 사항만 저장합니다.은 기본적인 것과 .git commit현재 분기 대신 상태가 스택에 커밋된 경우를 제외합니다.

늙은

최신 신최깃으수있다니습할용을 사용할 수 .--patch

git stash push --patch   # since 2.14.6

git stash save --patch   # for older git versions

또한 Git는 파일의 각 변경 사항을 추가할지 여부를 묻습니다.
은 그냥 만하세요답대라고 대답합니다.y또는n

이전 업데이트
DOUBLE STASH의 별칭:

git config --global alias.stash-staged '!bash -c "git stash --keep-index; git stash push -m "staged" --keep-index; git stash pop stash@{1}"'

이제파을다실수있다습니할행음을 실행할 수 .git stash-staged.
결과적으로 준비된 파일이 저장소에 저장됩니다.

준비된 파일을 보관하지 않고 해당 파일을 저장소로 이동하려는 경우.그런 다음 다른 별칭을 추가하고 실행할 수 있습니다.git move-staged:

git config --global alias.move-staged '!bash -c "git stash-staged;git commit -m "temp"; git stash; git reset --hard HEAD^; git stash pop"'

업데이트 2022-04-21

원래 질문 https://stackoverflow.com/a/70231955/2959469 에 대한 새로운 관용적 접근법인 @VonC의 답변을 사용하면 됩니다.


TL;기존 접근 방식에 대한 DR 그냥 추가-- $(git diff --staged --name-only) ㅠㅠ<pathspec>

여기 간단한 한 줄이 있습니다.

git stash -- $(git diff --staged --name-only)

메시지를 간단히 추가하려면 다음을 수행합니다.

git stash push -m "My work in progress" -- $(git diff --staged --name-only)

v2.17.1v2.21.0.windows.1에서 테스트됨

제한 사항:

  • 스테이징된 파일이 없는 경우 모든 항목이 저장됩니다.
  • 또한 부분적으로만 스테이징된 파일이 있는 경우(예: 일부 변경된 줄만 스테이징되고 일부 변경된 줄은 스테이징되지 않은 줄 포함) 전체 파일이 스테이징됩니다.

Git 2.35 (Q1 2022)로,git stash(man) "는--staged인덱스에 추가된 항목(다른 항목 제외)을 저장하는 옵션입니다.

따라서 이제 공식적으로 지원됩니다(8년 후).

a8a6e06(2021년 10월 28일)을 커밋하고, Sergey Organov()sorganov에 의해 41a28eb(2021년 10월 18일)을 커밋합니다.
(주니오 C 하마노에 의해 합병 -- -- 커밋 44ac8fd, 2021년 11월 29일)

'save' 및 'save'에 대해 '--session' stash옵션을 구현합니다.

사인 오프 바이: 세르게이 오르가노프

스테이징된 변경 사항만 저장합니다.

이 모드를 사용하면 현재 진행 중인 작업과 관련이 없는 일부 변경 사항을 나중에 다시 사용할 수 있도록 쉽게 저장할 수 있습니다.

과는리달'''와 stash push --patch',--staged에서는 '을(git add --interactive(man)를) 포함하여 모든 도구를 사용하여 저장할 변경 사항을 선택할 수 있습니다(이에 국한되지 않음).

git stash이제 관리 페이지에 다음 항목이 포함됩니다.

'git stash' [push [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-q|--quiet]

git stash이제 관리 페이지에 다음 항목이 포함됩니다.

save [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]

git stash이제 관리 페이지에 다음 항목이 포함됩니다.

-S

--staged

이 옵션은 다음 기간에만 유효합니다.push그리고.save명령을 실행합니다.

현재 준비된 변경 사항만 저장합니다.은 기본적인 것과 .git commit현재 분기 대신 상태가 스택에 커밋된 경우를 제외합니다.

--patch옵션이 이 옵션보다 우선합니다.

git stash이제 관리 페이지에 다음 항목이 포함됩니다.

Saving unrelated changes for future use

중인 할 없는 한 후 할 수 git stash push --staged나중에 사용할 수 있도록 보관합니다.
이는 스테이징된 변경 사항을 커밋하는 것과 유사하며 커밋 종료만 현재 분기에 있지 않고 저장소에 있습니다.

----------------------------------------------------------------
# ... hack hack hack ...
$ git add --patch foo           # add unrelated changes to the index
$ git stash push --staged       # save these changes to the stash
# ... hack hack hack, finish curent changes ...
$ git commit -m 'Massive'       # commit fully tested changes
$ git switch fixup-branch       # switch to another branch
$ git stash pop                 # to finish work on the saved changes
----------------------------------------------------------------

저는 현재 준비된 것만 스테이징하고 다른 것은 모두 남기는 스크립트를 만들었습니다.이것은 제가 너무 많은 관련 없는 변화를 만들기 시작할 때 멋진 일입니다.원하는 커밋과 관련되지 않은 것을 준비하고 그것만 보관하면 됩니다.

(시작점을 준 Bartwomiej 덕분입니다)

#!/bin/bash

#Stash everything temporarily.  Keep staged files, discard everything else after stashing.
git stash --keep-index

#Stash everything that remains (only the staged files should remain)  This is the stash we want to keep, so give it a name.
git stash save "$1"

#Apply the original stash to get us back to where we started.
git stash apply stash@{1}

#Create a temporary patch to reverse the originally staged changes and apply it
git stash show -p | git apply -R

#Delete the temporary stash
git stash drop stash@{1}

같은 일을 하는 것은...

  1. 작업할 파일만 준비합니다.
  2. git commit -m 'temp'
  3. git add .
  4. git stash
  5. git reset HEAD~1

쾅, 당신이 원하지 않는 파일들은 숨겨져 있습니다.원하는 파일이 모두 준비되었습니다.

2022년 1월 업데이트: Git 2.35가 출시되었으며,stash 제지원을 합니다.--staged매개 변수따라서 이 답변은 Git 2.35+에서 사용되지 않습니다.vonc: https://stackoverflow.com/a/70231955/430128 의 답변을 참조하십시오.

이전 답변:

Git에 인덱스(단계적 변화)만 저장하는 것은 필요 이상으로 어렵습니다.저는 잘 작동하기 위한 @Joe의 을 찾았고, 그것의 작은 변형을 다음과 같은 별칭으로 바꾸었습니다.

stash-index = "!f() { \
  ! git diff --cached --exit-code --quiet && \
  git stash push --quiet --keep-index -m \"temp for stash-index\" && \
  git stash push \"$@\" && \
  git stash pop --quiet stash@{1} && \
  git stash show -p | git apply -R; }; f"

내용:

  1. 변경 사항이 합니다.git diff --cached --exit-code0이 아닌 상태(있는 경우)를 반환합니다.HT: @난딜루지오

  2. 이는 스테이징된 변경사항과 스테이징되지 않은 변경사항을 모두 일시적인 저장소로 밀어넣어 스테이징된 변경사항을 그대로 둡니다.

  3. 그런 다음 스테이징된 변경 사항을 보관하려는 저장소로 밀어넣습니다.예 다과같인별전습니다었달되칭에수음--message "whatever"이 stash 명령에 추가됩니다.

  4. 임시 저장소를 열어 원래 상태를 복원하고 임시 저장소를 제거한 다음

  5. 마지막으로 역방향 패치 응용 프로그램을 통해 작업 디렉터리에서 저장된 변경 사항을 "제거"합니다.

않은 스징되지가않변저경반문우는의제대하장)stash-working) 이 답변을 참조하십시오.

이 시나리오에서는 각 이슈에 대해 새 분기를 만드는 것을 선호합니다.접두사 temp/를 사용하므로 나중에 이 분기를 삭제할 수 있습니다.

git checkout -b temp/bug1

bug1을 수정하는 파일을 스테이징하고 커밋합니다.

git checkout -b temp/bug2

그런 다음 필요에 따라 각 분기에서 커밋을 선택하고 꺼내기 요청을 제출할 수 있습니다.

사용할 수 있습니다.--staged스테이징된 변경 사항만 저장합니다.

git stash --staged

설명서: https://git-scm.com/docs/git-stash#Documentation/git-stash.txt-push-p--patch-S--staged-k--no-keep-index-u--include-untracked-a--all-q--quiet-m--messageltmessagegt--pathspec-from-fileltfilegt--pathspec-file-nul--ltpathspecgt82308203

특정 버그에 대한 변경을 커밋하고 해당 커밋과 이전 버그에서 패치를 생성하는 것은 어떻습니까?

# hackhackhack, fix two unrelated bugs
git add -p                   # add hunks of first bug
git commit -m 'fix bug #123' # create commit #1
git add -p                   # add hunks of second bug
git commit -m 'fix bug #321' # create commit #2

다음 패치를 그런다음패치생면다사다니용합음을려성하를을 사용합니다.git format-patch:

git format-patch HEAD^^

이렇게 하면 두 개의 파일이 만들어집니다.0001-fix-bug-123.patch그리고.0002-fix-bug-321.patch

또는 각 버그에 대해 별도의 분기를 만들어 버그 수정을 개별적으로 병합하거나 기본 재배치할 수 있으며, 해결되지 않는 경우 삭제할 수도 있습니다.

git stash --keep-index좋은 해결책은...Git 2.23(2019년 3분기)에서 수정된 제거된 경로에서 올바르게 작동하지 않았다는 점만 제외합니다.

Thomas tgummererGummerer()의 commit b932f6a(2019년 7월 16일)를 참조하십시오.
(Junio C Hamano에 의해 합병됨 -- -- commit f8aee85, 2019년 7월 25일)

stash를 수정하려면 " 된처수정리제"를 사용합니다.--keep-index

git stash push --keep-index에서는 인덱스와 디스크 모두에서 인덱스에 추가된 모든 변경 사항을 유지해야 합니다.

현재 인덱스에서 파일을 제거할 때 이 기능이 제대로 작동하지 않습니다.
디스크에서 삭제된 상태로 유지하는 대신 **--keep-index는 현재 파일을 복원합니다.**

'을(를) 사용하여 해당 동작을 수정합니다.git checkout인덱스와 작업 트리를 정확하게 복원할 수 있는 무반복 모드입니다.
이것은 또한 코드를 단순화합니다.

추적되지 않은 파일의 이름이 인덱스에서 삭제된 파일과 동일한 경우 추적되지 않은 파일을 덮어씁니다.

이에 대한 또 다른 접근 방식은 저장하지 않을 파일로 임시 커밋을 만든 다음 남은 파일을 저장하고 마지막 커밋을 부드럽게 제거하여 파일을 그대로 유지하는 것입니다.

git add *files that you don't want to be stashed*
git commit -m "temp"
git stash --include-untracked
git reset --soft HEAD~1

이렇게 하면 원하는 파일만 터치할 수 있습니다.

여기서 "--include-untracked"는 새 파일을 저장하는 데도 사용됩니다(아마도 정말 원하는 파일일 것입니다).

만약 당신이 더 새로운 Git을 가지고 있지 않다면.--staged옵션, 여기 직접 수행하는 방법이 있습니다.

git stash명령은 트리 개체와 커밋 등을 조작하는 복잡한 셸 스크립트일 뿐입니다.우리는 그것이 하는 일을 수동으로 할 수 있습니다.

개요

스택은 특수 커밋을 기록합니다.준비된 변경 사항에서 커밋을 생성한 다음 수동으로 스택으로 전송합니다.그런 다음 커밋을 제거합니다.

설정

나는 두 가지 변경 사항이 있는 프로젝트가 있습니다.Makefile하나는 스테이징되고 하나는 스테이징되지 않습니다.

$ git diff --cached
diff --git a/Makefile b/Makefile
index 4ca6058f..c8c7480a 100644
--- a/Makefile
+++ b/Makefile
@@ -605,7 +605,7 @@ conftest2: conftest1.c conftest2.c
        $(V)if echo | $(CC) -dM -E - | grep -s __ANDROID__ >  /dev/null 2>&1 ; then \
          echo yes ; \
        fi
-
+# FOO
 .PHONY: conftest.clean
 conftest.clean:
        $(V)rm -f conftest$(EXE) conftest.[co] \

$ git diff
diff --git a/Makefile b/Makefile
index c8c7480a..270c313d 100644
--- a/Makefile
+++ b/Makefile
@@ -611,3 +611,4 @@ conftest2: conftest1.c conftest2.c
        $(V)rm -f conftest$(EXE) conftest.[co] \
        conftest2$(EXE) conftest[12].[oc] \
        conftest.err
+# BAR

.# FOO됨; 됨; 추가됨# BAR미스테이지입니다.

1단계: 트리 개체를 만듭니다.

먼저 현재 인덱스(준비된 항목을 포함)에서 트리 개체를 만듭니다.

$ git write-tree
0d9651ad74328e747a053a9434d9867c8cd79d41 <-- output

2단계: 두 개의 커밋을 만듭니다.

부모가 분기인 트리에서 .HEAD:

$ git commit-tree -p HEAD -m 'add # FOO' 0d9651ad74328e747a053a9434d9867c8cd79d41
baa34222e781078d82cefed519ff105715c7f665 <-- output

다음,의 부모가 : 그다두개부있는다만커듭다니밋을른트서리에런모.HEAD 리고그고.baa34222...방금 한 약속:

$ git commit-tree -p HEAD -p baa34222e781078d82cefed519ff105715c7f665 -m 'add # FOO' 0d9651ad74328e747a053a9434d9867c8cd79d41
2c96b028e475a05d84f472da7f2a70ac53d0ac90 <-- output

두 부모는 이친입니다.2c96b02...우리가 창고에 설치하는 커밋이 될 것입니다.

:git commit-tree아닙니다git commit하위 수준의 명령입니다.이러한 커밋은 현재 분기에 아무런 영향을 미치지 않습니다. Git의 저장소에 있는 개체를 할당하는 것일 뿐이며, 현재 있는 분기나 인덱스 또는 작업 트리를 변경하는 것은 아닙니다.

3단계.

이 을 다으로이다씁니다에음커에 씁니다..git/refs/stash이 파일을 백업할 수 있습니다.

$ echo 2c96b028e475a05d84f472da7f2a70ac53d0ac90 > .git/refs/stash

4단계.

에 연결합니다..git/logs/refs/stash파일. 편집하기 전에 파일의 마지막 줄은 다음과 같습니다.

b1819d98ab24720796315b9497236172d1fb1f5f 3b2ecc6604d77c9df4fe72efd1fbd384b2c43f76 Au Thor <author@example.com> 1654892876 -0700 On master: elim-aliases

이 가짜 라인을 수동으로 추가합니다.

3b2ecc6604d77c9df4fe72efd1fbd384b2c43f76 2c96b028e475a05d84f472da7f2a70ac53d0ac90 Au Thor <author@example.com> 1654892876 -0700 On master: add # FOO

이 파일을 백업할 수도 있습니다.하지만, 만약 어떤 일이 잘못되면, 그것들은 복원하기 쉽습니다.

왼쪽 해시에 유의하십시오.3b2ecc...이 새 행은 이전 행의 오른쪽 해시와 동일합니다.이것은 우리가 여기서 하고 있는 것과 무관한 이전의 스택 커밋이며, 이 라인을 스택에 연결하기 위해 반복해야 합니다.그 오른쪽에는 우리의 해시가 있습니다.2c96b028e4...그리고 나머지 사람들은 거짓으로 행동했습니다. 준표시뒤대에하탭있다니습이 에 하드 탭이 .-0700공백이 아닙니다.방금 복사해서 붙여놨어요.

5단계.

커밋이 스택에 추가되었는지 확인합니다.

$ git stash list | head -3
stash@{0}: On master: add # FOO
stash@{1}: On master: elim-aliases
stash@{2}: On master: compiler-safe-eval

그리고:

$ git stash show -p
diff --git a/Makefile b/Makefile
index 4ca6058f..c8c7480a 100644
--- a/Makefile
+++ b/Makefile
@@ -605,7 +605,7 @@ conftest2: conftest1.c conftest2.c
        $(V)if echo | $(CC) -dM -E - | grep -s __ANDROID__ >  /dev/null 2>&1 ; then \
          echo yes ; \
        fi
-
+# FOO
 .PHONY: conftest.clean
 conftest.clean:
        $(V)rm -f conftest$(EXE) conftest.[co] \

있습니다; 여기있습다니;다;git stash우리의 약속이 "재고 같은" 약속이라고 생각하고 그것을 받아들입니다.

요약

  1. 우리는 수동으로 단계적 변경을 통해 인덱스를 가져와 트리 객체를 생성했습니다.

  2. 그런 다음 트리 개체를 일반 커밋 개체로 전환한 다음 두 부모 커밋을 하나 더 추가했습니다.두 부모 개체는 저장소와 같은 커밋으로 사용할 수 있습니다.

  3. 마지막으로 파일 쌍을 편집하여 이 커밋을 수동으로 스택에 패치했습니다.

부록

인덱스 또는 작업 트리를 조작하는 안전하지 않은 명령을 실행하지 않았습니다.그러나 Gitstash 스택을 안전하게 조작했습니다.문제가 발생할 경우 백업 파일에서 복원하지 않고 다음을 해결하는 방법을 설명합니다.

  1. 을 하세요..git/logs/refs/stash다시 한 번 이것이 마지막 줄이 될 것입니다.

    b1819d98ab24720796315b9497236172d1fb1f5f 3b2ecc6604d77c9df4fe72efd1fbd384b2c43f76 Au Thor <author@example.com> 1654892876 -0700 On master: elim-aliases
    
  2. 해시를 합니다.3b2ecc6604d77c9df4fe72efd1fbd384b2c43f76그리고 그것을 그 안에 심습니다..git/refs/stash파일 이름:

    $ echo 3b2ecc6604d77c9df4fe72efd1fbd384b2c43f76  > .git/refs/stash`
    

이제 이전 스택이 복원됩니다.

한 번에 여러 개의 버그를 수정할 필요가 있습니까?그리고 "한 번에"란 "여러 버그를 동시에 편집할 수 있는 파일"을 의미합니다.당신이 꼭 필요하지 않다면, 저는 당신의 환경에서 한 번에 하나의 버그만 처리할 것이기 때문입니다.이렇게 하면 복잡한 저장소/단계를 관리하는 것보다 훨씬 쉬운 로컬 지점 및 기본 재배치를 사용할 수 있습니다.

마스터가 커밋 B에 있다고 가정합니다.이제 1번 버그를 처리합니다.

git checkout -b bug1

이제 당신은 branch bug1에 있습니다.변경하고, 커밋하고, 코드 검토를 기다립니다.이것은 로컬이기 때문에 다른 사람에게 영향을 미치지 않으며, git diff에서 패치를 만들기에 충분히 쉬울 것입니다.

A-B < master
   \
    C < bug1

이제 버그2 작업을 하고 있군요.마스터로 돌아가기git checkout master지점을 , 새가를만들고지,,git checkout -b bug2변경하고, 커밋하고, 코드 검토를 기다립니다.

    D < bug2
   /
A-B < master
   \
    C < bug1

검토 대기 중인 동안 다른 사람이 마스터에 대해 E&F를 수행한다고 가정해 보겠습니다.

    D < bug2
   /
A-B-E-F < master
   \
    C < bug1

코드가 승인되면 다음 단계를 수행하여 코드의 기본을 변경하여 마스터할 수 있습니다.

git checkout bug1
git rebase master
git checkout master
git merge bug1

그러면 다음과 같은 결과가 발생합니다.

    D < bug2
   /
A-B-E-F-C' < master, bug1

그런 다음 로컬 bug1 브랜치를 누르고 삭제한 후 바로 이동할 수 있습니다.작업 공간에서 한 번에 하나의 버그가 발생하지만 로컬 분기를 사용하면 저장소에서 여러 버그를 처리할 수 있습니다.이렇게 하면 복잡한 무대/스택 댄스를 피할 수 있습니다.

댓글에 있는 ctote의 질문에 대한 답변:

각 버그에 대한 저장으로 돌아가서 한 번에 하나의 버그만 처리할 수 있습니다.적어도 준비 문제는 해결할 수 있습니다.하지만 이것을 시도해 본 결과, 저는 개인적으로 그것이 귀찮다고 생각합니다.Git 로그 그래프에서는 스택이 약간 지저분합니다.그리고 더 중요한 것은, 무언가를 망치면 되돌릴 수 없다는 것입니다.작업 디렉터리가 더러워져 있고 저장소를 팝업하면 해당 팝업을 "실행 취소"할 수 없습니다.이미 존재하는 커밋을 망치는 것이 훨씬 더 어렵습니다.

그렇게git rebase -i.

한 분기를 다른 분기로 기본 재배치할 때 대화형으로 수행할 수 있습니다(-i 플래그).이렇게 하면 각 커밋에서 수행할 작업을 선택할 수 있습니다.ProGit은 HTML 형식으로도 온라인으로 제공되는 멋진 책이며, 리베이스 및 스쿼시에 대한 멋진 섹션이 있습니다.

http://git-scm.com/book/ch6-4.html

편의상 그들의 예를 그대로 도용하겠습니다.다음과 같은 커밋 기록이 있고 bug1을 마스터로 리베이스 & 스쿼시하고 싶다고 가정합니다.

    F < bug2
   /
A-B-G-H < master
   \
    C-D-E < bug1

▁you를 입력하면 다음과 같이 git rebase -i master bug1

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

분기의 모든 커밋을 단일 커밋으로 압축하려면 첫 번째 커밋을 "선택"으로 유지하고 이후의 모든 "선택" 항목을 "스쿼시" 또는 단순히 "s"로 바꿉니다.커밋 메시지를 변경할 수도 있습니다.

pick f7f3f6d changed my name a bit
s 310154e updated README formatting and added blame
s a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit

그래서 네, 찌그러뜨리는 것은 약간 고통스럽지만, 저는 여전히 과도한 끈 사용보다는 그것을 추천하고 싶습니다.

Mike Monkiewicz의 답변에 대한 귀하의 의견 중에서 저는 더 간단한 모델을 사용할 것을 제안합니다.일반 개발 분기를 사용하지만 병합의 스쿼시 옵션을 사용하여 마스터 분기에서 단일 커밋을 가져옵니다.

git checkout -b bug1    # create the development branch
* hack hack hack *      # do some work
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
git checkout master     # go back to the master branch
git merge --squash bug1 # merge the work back
git commit              # commit the merge (don't forget
                        #    to change the default commit message)
git branch -D bug1      # remove the development branch

이 절차의 장점은 일반적인 git 워크플로우를 사용할 수 있다는 것입니다.

실수로 인한 변경(특히 여러 파일 삭제)을 제거하려면 다음 작업을 수행합니다.

git add <stuff to keep> && git stash --keep-index && git stash drop

즉, 쓰레기를 쌓아두고 쓰레기와 함께 모두 버리세요.

Git 버전 2.17.1에서 테스트됨

사용할 필요가 없는 이 솔루션을 본 적이 없습니다.git stash:

사용할 필요도 없습니다.git stash조금도.여기에 설명된 대로 전용 지점을 사용하여 이 문제를 해결할 수 있습니다(지점은 저렴합니다).

실제로 다음과 같은 몇 개의 연속된 명령을 사용하여 준비되지 않은 변경 사항을 별도로 분리하여 Git 별칭으로 함께 묶을 수 있습니다.

단계별 및 단계별 변경사항을 커밋할 새 분기를 만들고 전환합니다. 여기를 참조하십시오.

언제든지 할 수 있습니다.git cherry-pick -e 위치에 (생성된분한서원위적치용에하는여하커밋기()-e커밋 메시지를 변경합니다.

더 이상 필요하지 않을 때 이 "stash branch"를 삭제할 수 있습니다.사해야할있다니습수도용을 해야 할 .-D삭제 (" " " " " " ( " " " "의 정의)의 정의입니다.-doptional)은 해당 되지 않고 위험이 할 수 때문입니다. normal optional)은 다음과 같습니다.삭제하기 전에 해당 커밋을 체리로 선택하지 않은 경우에는 해당됩니다.

git branch -D separated-stashes

에별을추수있다습에 .~/.gitconfig동작을 하려면 다음을 수행합니다.

git config --global alias.bratisla '!git switch -c separated-stashes; git commit -m "staged changes"; git add -u; git commit -m "unstaged changes"; git switch -' # why this name ? : youtu.be/LpE1bJp8-4w

"스토킹"하기 전에
"고치기"



물론, 두 개의 연속적인 스테이시를 사용하여 동일한 결과를 얻을 수도 있습니다.

다른 답변에서 언급한 것처럼 다음을 사용하여 단계별 또는 단계별 변경사항만 저장할 수 있습니다.git stash (-k|--keep-index)다른 명령과 함께 사용할 수 있습니다.

저는 개인적으로 그것을 발견합니다.-k 사항을 로 유지하기 혼란스럽습니다(" 옵션모것든스을변스만된징사다테이니혼습스럽스란경매때상우유기문에하된지은태징테로이항은").--keep-index하는 것은 으로 이동시킵니다.") 반면에 무언가를 저장하는 것은 일반적으로 그것을 저장 항목으로 이동시킵니다.와 함께-k스테이징되지 않은 변경 내용은 일반적으로 스테이징되지만 스테이징된 변경 내용은 동일한 스테이징 항목에 복사됩니다.


0단계: Git 상태에는 두 가지가 있습니다. 즉, 준비된 변경사항이 들어 있는 파일과 준비되지 않은 변경사항이 들어 있는 파일입니다.

1단계: 스테이징되지 않은 + 스테이징된 변경은 저장하지만 스테이징된 변경은 인덱스에 유지합니다.

git stash -k -m "all changes"

-m "..."부품은 선택 사항입니다.git stash -k 에대 별다니입칭의 입니다.git stash push -k(원격으로 아무것도 밀지 않지만 걱정하지 마세요) 이것은 a를 받아들입니다.-m명확성을 위해 (커밋 메시지 또는 태그와 같이) 저장 항목에 레이블을 지정하는 옵션입니다.은 더 되지 않는 더이사지않버다전니입최신는용되상▁의 최신 입니다.git stash save.


1단계 bis(선택 사항):

git stash

준비된 변경 사항(아직 인덱스에 있음)을 저장합니다.이 단계는 다음과 같은 경우에는 필요하지 않지만, 원하는 경우 스테이징된 변경 사항만 스택 항목에 넣을 수 있음을 보여줍니다.이 라인을 사용하면 다음과 같이 해야 합니다.git stash (pop|apply) && git add -u2 단계를 하기 전에.


2단계:

git commit -m "staged changes"

0단계의 단계별 변경 내용만 포함하는 커밋을 수행하며, 1bis 단계의 stash 항목과 동일한 내용을 포함합니다.


3단계:

git stash (pop|apply)

1단계부터 스택을 복원합니다.이 저장소 항목에는 모든 항목이 포함되어 있지만 이미 준비된 변경 사항을 커밋했으므로 이 저장소는 0단계부터 준비되지 않은 변경 사항만 추가합니다.

nb: 여기서 "restore"는 다른 명령인 "git restore"를 의미하지 않습니다.


4단계:

git add -u

팝업 저장소의 내용을 인덱스에 추가합니다.


5단계:

git commit -m "unstaged changes"

여기서 "단계화되지 않음"은 2단계와 3단계 주석에서 "단계화됨"으로 0단계를 나타냅니다.실제로 0단계부터 "단계별 변경사항"을 준비하고 커밋하고 있습니다.


완료! 이제 0단계에서 변경된 (해제) 단계를 포함하는 두 개의 분리된 커밋이 있습니다.추가 변경사항에 대해 수정/기본값을 변경하거나 이름 변경/삭제/소멸할 수 있습니다.으로 무엇을 .pop또는apply), 당신은 또한 원할 수도 있습니다.git stash (drop|clear)항목을 저장하는 것을 볼 수 있습니다.git stash (list|show)

TL;DR;git stash-staged

별칭을 만든 후:

git config --global alias.stash-staged '!bash -c "git stash -- \$(git diff --staged --name-only)"'

여기서git diff의 합니다.--staged--name-only
그런 다음 이 목록을 다음과 같이 전달합니다.pathspecgit stash사령관의

man git stash:

git stash [--] [<pathspec>...]

<pathspec>...
   The new stash entry records the modified states only for the files
   that match the pathspec. The index entries and working tree
   files are then rolled back to the state in HEAD only for these
   files, too, leaving files that do not match the pathspec intact.

언급URL : https://stackoverflow.com/questions/14759748/how-can-i-stash-only-staged-changes-in-git

반응형