Git에서 커밋하기 전에 스테이지를 원하는 이유는 무엇입니까?
버전 관리는 처음이라 작업 중인 새로운 '현재' 버전을 업데이트하는 동안 "커밋"을 수행하는 것이 기본적으로 백업을 생성한다는 것을 알고 있습니다.
제가 이해할 수 없는 것은 무대가 실용적인 관점에서 무엇을 위한 것인지에 대한 것입니다.이름뿐인 것을 무대화하는 것은 목적에 맞는 것이 목적입니까?당신이 헌신할 때, 어쨌든 모든 것을 헌신할 것입니다, 그렇죠?
편집: 제가 용어를 혼동하고 있는 것 같습니다.'stageed' 파일은 'tracked' 파일과 동일합니까?
커밋하면 인덱스("스테이지" 파일)의 변경 사항만 커밋됩니다.여러 가지 용도로 사용할 수 있지만 가장 확실한 것은 작업 변경 사항을 더 작은 자체 부품으로 나누는 것입니다.기능을 구현하는 동안 버그를 수정했을 수도 있습니다.넌 할 수 있다.git add 그 또는일))git add -p파일의 일부만 추가할 수 있습니다.) 다른 모든 것을 커밋하기 전에 버그 수정을 커밋합니다.git commit -a을 강요하는 .add약속 직전의 모든 것을 말입니다.사용하지않습니다.-a준비 파일의 이점을 이용하고자 하는 경우.
을 .--cached많은 명령에.를 들면,면,git diff --cached입니다와 .HEAD다른 작업 변경 사항을 변경하지 않고도 어떤 작업을 수행할지 확인할 수 있습니다.
- 스테이징 영역은 커밋을 더 작게 만들 수 있는 제어 기능을 제공합니다.코드를 논리적으로 한 번만 변경하고 변경된 파일을 스테이징 영역에 추가하면 마지막으로 변경 사항이 잘못된 경우 이전 커밋으로 체크아웃하거나 변경 사항을 커밋하면 됩니다.작업을 더 작은 작업으로 나누고 더 작은 변경 사항을 실행할 수 있는 유연성을 제공합니다.준비 영역을 사용하면 작은 작업에 더 쉽게 집중할 수 있습니다.
- 또한 휴식을 취하고 휴식하기 전에 얼마나 많은 일을 했는지 잊어버릴 수 있는 기회도 제공합니다.하나의 논리적인 변경을 위해 세 개의 파일을 변경해야 하고 첫 번째 파일을 변경했으며 다른 변경을 시작할 때까지 긴 휴식이 필요하다고 가정합니다.지금은 커밋을 할 수 없으며 작업이 완료된 파일을 추적하여 작업이 완료된 후 작업량을 기억할 필요가 없습니다.따라서 준비 영역에 파일을 추가하면 작업이 절약됩니다.만 하세요.
git diff --staged그리고 어떤 파일을 변경했는지, 어디서 다른 변경을 시작했는지 확인합니다.
스테이징의 실질적인 목적 중 하나는 파일 커밋을 논리적으로 분리하는 것입니다.
스테이징을 사용하면 파일/작업 디렉토리에 대한 편집을 계속할 수 있고 준비가 되었다고 생각될 때 부분적으로 커밋을 수행할 수 있으므로 논리적으로 관련이 없는 편집에 별도의 단계를 사용할 수 있습니다.
4개의 파일이 있다고 가정해 보겠습니다.fileA.html,fileB.html,fileC.html그리고.fileD.html .합니다.fileA.html그리고.fileB.html 두 한 새 다의 예:현)이 있습니다.fileC.html그리고.fileD.html파일과는 별개이며 논리적으로 이전 파일과는 무관합니다.다 할 수 .fileA.html그리고.fileB.html그것들을 저지를 겁니다.
git add fileA.html
git add fileB.html
git commit -m "Implemented new feature XYZ"
그런 다음 단계에서 나머지 두 개의 파일에 대한 변경사항을 준비하고 커밋합니다.
git add fileC.html
git add fileD.html
git commit -m "Implemented another feature EFG"
Ben Jackson의 답변을 자세히 살펴보기 위해, 원래 질문을 자세히 살펴보도록 하겠습니다. (왜 성가시게 질문을 입력하는지는 그의 답변을 참조하십시오. 이것은 무슨 일이 일어나고 있는지에 대한 것입니다.)
버전 관리는 처음이라 작업 중인 새로운 '현재' 버전을 업데이트하는 동안 "커밋"을 수행하는 것이 기본적으로 백업을 생성한다는 것을 알고 있습니다.
이것은 완전히 옳지 않습니다.백업과 버전 제어는 어느 정도 의견의 문제인 몇 가지 사항에 따라 정확히 어느 정도의 차이가 나는지와 관련이 있습니다. 백업은 일반적으로 재해 복구(기계 고장, 화재로 인해 모든 저장 매체를 포함한 건물 전체가 파괴되는 등)를 위해 설계됩니다.버전 제어는 일반적으로 세분화된 상호 작용을 위해 설계되었으며 백업에서는 제공하지 않는 기능을 제공합니다.백업은 일반적으로 일정 기간 저장된 후 "너무 오래된" 상태로 폐기됩니다. 백업만 새로 하면 됩니다.버전 제어는 일반적으로 모든 커밋된 버전을 영원히 저장합니다.
제가 이해할 수 없는 것은 무대가 실용적인 관점에서 무엇을 위한 것인지에 대한 것입니다.이름뿐인 것을 무대화하는 것은 목적에 맞는 것이 목적입니까?당신이 헌신할 때, 어쨌든 모든 것을 헌신할 것입니다, 그렇죠?
한마디로 이야기할 수 없군요.여기 깃의 디자인은 좀 특이합니다.별도의 준비 단계가 필요 없는 버전 제어 시스템이 있습니다.예를 들어, Mercurial은 Git와 사용량 면에서 많이 유사하므로 별도의 정보를 필요로 하지 않습니다.hg add새로운 파일을 처음 도입하는 단계를 넘어 단계적어도 마찬가지입니다.면을 할 수 있고,라면hg입니다.hg commit 넌 끝이야 깃하면,git checkout,1일을1 한 다음에 도망쳐요git add,그리고 나서.git commit로.git add텝?
여기서 비밀은 Git가 다양하게 인덱스 또는 스테이징 영역이라고 부르는 것, 또는 드물게 요즘은 캐시라고 부르는 것입니다.이것들은 모두 같은 것에 대한 이름입니다.
편집: 제가 용어를 혼동하고 있는 것 같습니다.'stageed' 파일은 'tracked' 파일과 동일합니까?
아니요, 하지만 이들은 관련이 있습니다.추적된 파일은 Git의 인덱스에 존재하는 파일입니다.지수를 제대로 이해하려면 커밋을 이해하는 것부터 시작하는 것이 좋습니다.
Git version 2.23 1이후로 사용할 수 있습니다.git switchgit checkout 이 두 이 경우 이 두 명령은 정확히 동일한 작업을 수행합니다.는 다음과 같습니다.git checkout너무 d을 로 고,서,git switch그리고.git restore, Git을 더 쉽고 안전하게 사용할 수 있도록 하기 위해서입니다.
커밋
Git에서 커밋은 Git이 알고 있는 모든 파일의 전체 스냅샷을 저장합니다.(Git이 알고 있는 파일은?다음 섹션에서 확인하겠습니다.)이러한 스냅샷은 읽기 전용, Git 전용, 압축 및 중복 제거된 특수한 형태로 저장되며, 일반적으로 Git 자체만 읽을 수 있습니다.(각 커밋에는 이 스냅샷보다 더 많은 내용이 포함되지만 여기서는 여기까지만 다루도록 하겠습니다.)
중복 제거는 공간 확보에 도움이 됩니다. 보통 몇 개의 파일만 변경한 다음 새로운 커밋을 수행합니다.따라서 커밋의 대부분의 파일은 이전 커밋의 파일과 대부분 동일합니다.이러한 파일을 직접 재사용하기만 하면 Git은 많은 공간을 절약할 수 있습니다. 파일 하나만 터치해도 새 커밋은 새 복사본 하나에 공간만 차지합니다.이 경우에도 압축됩니다. 때로는 매우 압축되기도 하지만 실제로는 나중에 발생합니다..git디렉토리는 일반 일상 파일로 확장되면 포함된 파일보다 실제로 더 작을 수 있습니다.중복 제거는 커밋된 파일이 항상 동결되므로 안전합니다.아무도 가서 바꿀 수 없기 때문에 커밋이 서로의 복사본에 의존하는 것은 안전합니다.
저장된 파일이 항상 동결된 Git 전용의 특별한 형식이기 때문에 Git는 각 파일을 일상적인 복사본으로 확장해야 합니다.이 평범한 복사본은 Git의 복사본이 아닙니다. 당신이 원하는 대로 할 수 있는 당신의 복사본입니다.Git은 당신이 그렇게 하라고 할 때 그냥 그들에게 편지를 써서 당신이 작업할 복사본을 가질 수 있도록 할 것입니다.이러한 사용 가능한 복사본은 작업 트리 또는 작업 트리에 있습니다.
이것은 특정 커밋을 체크아웃할 때 각 파일의 복사본이 자동으로 두 개가 된다는 것을 의미합니다.
깃은 현재 커밋에서 항상 동결된 깃 형태의 복사본을 가지고 있습니다.물론 다른 커밋을 선택하거나 새 커밋을 수행할 수 있지만, 이 복사본은 변경할 수 없습니다.
작업 트리에 일반 형식의 복사본이 있습니다.컴퓨터의 명령을 사용하여 원하는 작업을 수행할 수 있습니다.
다른 버전 제어 시스템(위에서 언급한 Mercurial 포함)은 여기서 중지되며, 이 두 개의 복사본이 있습니다.작업 트리 복사본을 수정한 다음 커밋하면 됩니다.깃... 그렇지 않습니다.
지수를
이 두 복사본 사이에 Git은 모든 파일의 세 번째 복사본을2 저장합니다.이 세 번째 복사본은 고정된 형식이지만 커밋의 고정된 복사본과 달리 변경할 수 있습니다.변경하려면 다음을 사용합니다.git add.
git add명령어는 파일의 인덱스 복사본을 작업 트리 복사본과 일치시키라는 것을 의미합니다.즉, Git: 업데이트된 작업 트리 복사본을 압축하고 중복을 제거하여 새 커밋에 동결할 준비를 하는 방법으로 인덱스에 있는 동결 형식의 중복 제거 복사본을 교체합니다.사용하지 않을 경우git add합니다의 보유합니다.
는.git commit, Git은 인덱스에 있는 것은 무엇이든 바로 새로운 스냅샷으로 사용할 수 있도록 패키지를 만듭니다.Git은 이미 동결된 형식으로, 중복 제거된 상태이기 때문에 많은 추가 작업을 할 필요가 없습니다.
또한 추적되지 않은 파일이 무엇인지 설명합니다.추적되지 않은 파일은 워크 트리에는 있지만 현재 Git 인덱스에는 없는 파일입니다.파일이 이 상태로 어떻게 마무리되었는지는 중요하지 않습니다.컴퓨터의 다른 곳에서 워크트리로 복사했을 수도 있습니다.아마 당신이 여기서 새로 만들었을 겁니다.깃의 인덱스에 복사본이 있었을 수도 있지만, 당신은 그 복사본을 삭제했습니다.git rm --cached. 어떻게 해서든 여기 워크트리에는 복사본이 있지만 Git의 인덱스에는 복사본이 없습니다.지금 새 커밋을 수행하면 해당 파일은 새 커밋에 포함되지 않습니다.
:git checkout처음에는 체크아웃한 커밋에서 깃의 인덱스를 채웁니다.그래서 인덱스는 커밋과 일치하기 시작합니다.또한 Git는 동일한 소스로부터 워크 트리를 채웁니다.그래서 처음에는 셋 다 일치합니다.작업 트리의 파일을 변경할 때 및git add자,합니다.그럼 당신이 달려요git commit깃은 인덱스에서 새로운 커밋을 하고 이제 셋이 다시 일치합니다.
Git은 인덱스에서 새로운 커밋을 수행하기 때문에 다음 커밋을 수행할 수 있습니다. Git의 인덱스는 다음 커밋을 수행할 수 있습니다.이는 충돌된 병합 동안 Git의 인덱스가 맡게 되는 확장된 역할을 무시하는 것이지만, 어쨌든 일단은 무시하고자 합니다. :-)
그게 전부예요. 그래도 꽤 복잡해요!깃의 인덱스에 무엇이 있는지 정확히 알 수 있는 쉬운 방법이 없기 때문에 특히 까다롭습니다.3하지만 지금 무슨 일이 일어나고 있는지를 알려주는 Git 명령이 있습니다. 꽤 유용한 방법으로 말이죠. 그리고 그 명령은git status.
2엄밀히 말하면 이건 전혀 복사가 아닙니다.대신, 그것은 깃-아이피 파일, 사전-중복된 모든 것에 대한 참조입니다.여기에는 모드, 파일 이름, 스테이징 번호, Git을 빠르게 처리할 수 있는 캐시 데이터 등 더 많은 것들이 있습니다.하지만 깃의 하위 명령들을 사용하지 않는 한,git ls-files --stage그리고.git update-index특히, 복사라고 생각하시면 됩니다.
3더git ls-files --stage명령어는 Git의 인덱스에 있는 모든 파일의 이름과 준비 번호를 보여주지만, 일반적으로 이것은 그다지 유용하지 않습니다.
git status
git status 두 합니다를 합니다.git diff명령(예: 어느 지점에 있는지 알려주는 등의 기타 유용한 작업)을 수행합니다.
.git diff는 현재 커밋(항상 정지되어 있음)을 Git의 인덱스에 있는 것과 비교합니다.동일한 파일에 대해서는 Git에서 아무 말도 하지 않습니다.서로 다른 파일의 경우, Git은 이 파일이 커밋을 위해 준비되었음을 알려줄 것입니다.여기에는 모든 새 파일이 포함됩니다(커밋에 없는 경우).sub.py그 안에서, 하지만 그 지수는.sub.py 커밋에는 더 없는 파일되고,됩니다)이 추가됩니다.git rm),).
.git diff는 Git 인덱스의 모든 파일을 워크 트리의 파일과 비교합니다.동일한 파일에 대해서는 Git은 전혀 아무 말도 하지 않습니다.서로 다른 파일의 경우, Git은 이 파일이 커밋을 위해 준비되지 않았음을 알려줄 것입니다.첫 번째 diff와 달리 이 특정 목록에는 파일이 모두 새로워진 파일이 포함되어 있지 않습니다.untracked작업 트리에는 존재하지만 Git의 인덱스에는 존재하지 않으며 Git은 추적되지 않은 파일 목록에 추가할 뿐입니다.4
되지 않은 , ,git status파일 이름도 알려주겠지만 특별한 예외가 있습니다. 파일 이름이 a에 나열되어 있는 경우입니다..gitignore마지막 목록을 억제하는 파일입니다.추적된 파일(Git의 인덱스에 있는 파일)을 에 나열하는 것은 영향을 미치지 않습니다. 파일이 인덱스에 있으므로 에 나열되더라도 비교 및 커밋됩니다..gitignore. ignore 파일은 "추적되지 않은 파일" 불만만 억제합니다.5
의 짧은 버전을 사용할 4경우git status—git status -s—추적되지 않은 파일은 분리되어 있지 않지만 원리는 동일합니다.이와 같은 파일을 축적하면 다음과 같은 효과도 얻을 수 있습니다.git status디렉토리 이름을 인쇄하는 것만으로 추적되지 않은 파일의 이름을 요약할 수 있습니다.전체 목록을 가져오려면 다음을 사용합니다.git status -uall아니면git status -u.
파일을 5나열하면 다음과 같은 많은 파일 작업을 대량으로 추가할 수 있습니다.git add .아니면git add *추적되지 않은 파일을 건너뜁니다.요,요를 사용할 수이 은 좀 더 .git add --force일반적으로 건너뛸 파일을 추가합니다.으로 경미한 한 경우가 데,다:일 에 해당합니다..gitignore더 적절한 이름으로 불리워질 수 있습니다..git-do-not-complain-about-these-untracked-files-and-do-not-auto-add-them아니면 똑같이 통제할 수 없는 것.하지만 그건 너무 말도 안돼요..gitignore그렇다.
git add -u,git commit -a,
여기에 대해 알 수 있는 몇 가지 편리한 바로가기가 있습니다.
git add .는 현재 디렉터리와 모든 하위 디렉터리에 업데이트된 모든 파일을 추가합니다.이 점을 존중합니다..gitignore이 ,에git status, 자동으로 추가되지 않습니다.git add -u는 작업 트리의 모든 업데이트된 파일을 자동으로 추가합니다.6이는 추적된 파일에만 영향을 미칩니다.작업 트리 복사본을 제거한 경우 인덱스 복사본도 제거됩니다(git add인덱스를 워크 트리와 일치시키는 작업의 일부로 이 작업을 수행합니다.)git add -A달리는 것과 같습니다git add .작업 트리의 최상위 레벨에서 볼 수 있습니다(단, 각주 6 참조).
에, 를 할 수 .git commit -a, 도망치는 것과 거의 맞먹습니다7.git add -u그리고 나서.git commit을 할수 즉, 머큐리얼에서 편리한 것과 같은 행동을 할 수 있습니다.
으로 입니다.git commit -a :턴 :다를 합니다.git status종종 출력을 자세히 살펴보고, 예상했던 상태가 아닌 경우에는 왜 그런 것인지 파악합니다.사용.git commit -a은 너무 ..하지만 이것은 대부분 취향/의견의 문제입니다.
Git 버전이 Git 2.0보다 이전 버전인 6경우 여기에서 주의하십시오.git add -u현재 디렉터리와 하위 디렉터리에서만 작동하므로 워크 트리의 최상위 레벨로 먼저 올라가야 합니다.git add -A가 있습니다.option다.
7저는 거의 동등하다고 말합니다. 왜냐하면git commit -a추가 인덱스를 만들고 해당 다른 인덱스를 사용하여 커밋을 수행합니다.커밋이 작동하면 다음과 같은 효과를 얻을 수 있습니다.git add -u && git commit. 커밋이 작동하지 않는 경우(Git에서 커밋을 건너뛰게 하는 경우), 파일이 없습니다.git add주 Git 입니다로 돌아가기 입니다.
합니다를 합니다.git commit --only여기 있습니다. 이 경우 Git은 세 번째 인덱스를 생성합니다. 특히 사전 커밋 후크를 사용하는 경우에는 상황이 매우 까다로워집니다.이는 별도로 사용해야 하는 또 다른 이유입니다.git add작전.
git 의 이 더 .add그리고.commitGithub의 저장소에 로그 파일이 유지되는 것을 상상하면 됩니다.일반적인 프로젝트의 로그 파일은 다음과 같습니다.
---------------- Day 1 --------------------
Message: Complete Task A
Index of files changed: File1, File2
Message: Complete Task B
Index of files changed: File2, File3
-------------------------------------------
---------------- Day 2 --------------------
Message: Correct typos
Index of files changed: File3, File1
-------------------------------------------
...
...
...and so on
하루를 합니다.git pull다.git push부탁한다.그래서 하루의 기록 안에 있는 모든 것은 그들 사이에서 일어나는 일에 해당합니다.하루 중에 몇 개의 파일을 변경해야 하는 하나 이상의 논리적 작업을 완료합니다.해당 작업 중 편집된 파일은 색인에 나열됩니다.
이러한 하위 태스크(Task A 및 Task B)는 각각 개별 커밋입니다.git add명령어는 'Index of Files Changed' 목록에 파일을 추가합니다.이 과정을 '스테이지'라고도 부릅니다.git commit명령어는 사용자 지정 메시지와 함께 변경 사항 및 해당 인덱스 목록을 기록/최종화합니다.
여전히 Github에 있는 저장소의 로컬 복사본이 아닌 저장소의 로컬 복사본만 변경하고 있음을 기억하십시오.이 후 '깃 푸시'를 수행할 때에만 기록된 모든 변경 사항을 각 커밋에 대한 인덱스 파일과 함께 기본 저장소(Github)에 기록됩니다.
예를 들어 가상 로그 파일의 두 번째 항목을 얻으려면 다음 작업을 수행해야 합니다.
git pull
# Make changes to these files
git add File3 File4
# Verify changes, run tests etc..
git commit -m 'Correct typos'
git push
말해서, ,git add그리고.git commit에서는 기본 저장소에 대한 변경 내용을 체계적인 논리 하위 changes으로 분류할 수 있습니다.다른 답변들과 댓글들이 지적했듯이, 물론 그것들에는 더 많은 용도가 있습니다.그러나 이는 Svn과 같은 다른 인기 있는 시스템과는 달리 Git가 다단계 개정 제어 시스템이 되는 가장 일반적인 용도 중 하나이자 원동력이 됩니다.
이는 커밋할 파일을 선택할 수 있는 기능을 제공하는 확인란과 같습니다.
를 들어,가 를 했다면,fileA.txt그리고.fileB.txt 저는 의 fileA.txt지가 입니다. 아직 끝나지 않았기 때문입니다.fileB.txt.
간단히 사용할 수 있습니다.git add fileA.txt합니다 사용을 합니다.git commit -m "changed fileA.txt"그리고 계속해서 함께 일을 하고 있습니다.fileB.txt할 수 있습니다.fileB.txt 쉬운
스테이징 영역은 커밋을 유연하게 제작하는 데 도움이 됩니다.제 말은 커밋을 논리적인 단위로 나눈다는 뜻입니다.유지 관리 가능한 소프트웨어를 원하는 경우 이는 매우 중요합니다.이를 달성할 수 있는 가장 확실한 방법은 다음과 같습니다.
하나의 작업 디렉토리에서 여러 기능/버그를 작업하면서도 의미 있는 커밋을 만들 수 있습니다.작업 디렉토리 하나에 활성화된 작업을 모두 포함하는 것도 매우 편리합니다. (변경 사항이 파일과 중복되지 않는 한, 준비 영역 없이 수행할 수 있습니다.중복 여부를 수동으로 추적해야 하는 추가 책임도 있습니다.)
여기서 더 많은 예를 찾을 수 있습니다.색인의 용도
그리고 가장 좋은 점은 이점이 이 워크플로우 목록에서 그치지 않는다는 것입니다.고유한 워크플로우가 나타나면 준비 영역이 도움이 될 것이라고 확신할 수 있습니다.
누가 이 끔찍한 코드를 작성하고 댓글을 유지하지 않았습니까?이런, 심지어 코드가 컴파일되지 않게 하는 버그도 있습니다.컴파일이 되더라도 실행 속도가 느립니다.
다 했어요.
$ git diff
어떤 끔찍한 법전
-
for(int i = 0; i < 20; i++)-
this.assets[i] = clear();+
foreach(var asset in assets) {+
asset = clear()+
}
문서화되지 않은 Api
+
//This Api has only one public method and only handles degrees Celsius+
//It is the onus of the user of the Api to conduct conversions
버기코드
+
size_t NumberOfElements = sizeof(arr)/sizeof(arr[0]);+
balance[NumberOfElements - 1];
슬로우코드
+
i = * ( long * ) &y; // evil floating point bit level hacking+
i = 0x5f3759df - ( i >> 1 ); // what the ****?
나는 넋이 나갔다.작은 변화를 주고 싶었지만 결국 한 번에 모든 것을 하게 되었습니다.약속할게요.
$ git commit -m "fixed some terrible code and added api documentation and fixed some compile time errors. Also introduced fast inverse square root"
자, 입력하고 커미...아그 잠깐만.저는 사실 전혀 다른 네 가지 일을 했습니다.
- 깃로그를 추적하는 것은 악몽이 될 것입니다.그리고 미래에만 나타나는 회귀 오류를 소개하면 어떨까요?오류 도입의 "정확한 커밋"을 찾는 것은 더 어려울 것입니다.
음, 그건 쉬운 일입니다.한 명씩 한 명씩 해볼게요.우선 다음과 같이 시작:
$ git commit someTerribleCode.foo -m "cleaned up the iteration loop"
아니, 기다려. 일이 다 .
someTerribleCode그리고.undocumentedApi그리고.HEAD.에 .
slowCode업데이트가 성능 향상을 능가합니다.저는 사실 그런 짓을 하면 안 됩니다.
그 피니쉬/스웨덴 사람이 이 도구를 줄 때 이 디자인 기준을 고려했다면 더 좋았을 겁니다.아, 잠깐만, 그가 했습니다.
$ git add undocumentedApi buggyCode
$ git diff --cached
문서화되지 않은 Api
+
//This Api has only one public method and only handles degrees Celsius+
//It is the onus of the user of the Api to conduct conversions
버기코드
+
size_t NumberOfElements = sizeof(arr)/sizeof(arr[0]);+
balance[NumberOfElements - 1];
좋은 것 같군요.그 두 가지를 한번에 해보겠습니다.연관성이 있는 것이 아니라 댓글로 구성된 것이기 때문에 저는 스트레스를 받지 않습니다.
$ git commit -m "fixed bug and added documentation"
다음은 별도의 약속:
$ git add someTerribleCode
$ git commit -m "refactored for loop"
준비 구역에 남아있는 것을 확인해 보겠습니다.
$ git status
Changes not staged for commit:
modified: slowCode
그런 변화들을 없앨 수 있습니다.
$ git reset --hard
깃은 무대화 영역을 완전히 피하고 오히려 "선택적 직접 커밋"을 설계할 수 있었지만, 이는 명령어 라인과 다양한 명령어를 이해하는 정신 모델과 인터페이스할 때 직관성이 떨어집니다. 무대화 영역의 정신적 모델을 구축하면 명령이 더욱 입맛에 맞고 이해하기 쉬워집니다.
@Ben Jackson과 @Tapashee Tabassum Urmi가 언급한 대로 스테이지를 사용하여 커밋을 더 작게 만드는 것이 중요하다고 생각합니다. 그리고 때로는 그러한 목적으로 커밋을 사용하기도 하지만, 주로 커밋을 더 크게 만드는 데 사용합니다.제 요점은 이렇습니다.
몇 가지 작은 단계가 필요한 작은 기능을 추가하고 싶다고 가정해 보겠습니다.더 작은 단계를 위한 별도의 커밋을 하고 타임라인을 플러딩하는 것은 의미가 없습니다.하지만 저는 각 단계를 저장하고 필요하다면 돌아가고 싶습니다.
저는 단지 작은 단계들을 서로의 위에 올려놓고, 그것이 헌신할 가치가 있다고 생각될 때, 저는 약속합니다.이렇게 하면 타임라인에서 불필요한 커밋을 제거하지만 마지막 단계를 실행 취소(체크아웃)할 수 없습니다.
선호도에 따라 사용할 수 있는 다른 방법(git 히스토리 단순화)이 있습니다.
- git 수정(마지막 커밋을 변경함)은 이 특정 목적을 위해 원하는 것이 아닙니다(대부분 잘못된 커밋을 한 후 수정하는 것으로 봅니다).
- git rebase는 뒤늦은 생각이며 사용자와 저장소를 사용하는 다른 사람들에게 심각한 문제를 일으킬 수 있습니다.
- 임시 분기를 생성하고 병합한 다음 삭제합니다(또한 좋은 옵션이며, 더 많은 단계가 필요하지만 제어력이 더 높습니다).
언급URL : https://stackoverflow.com/questions/4878358/why-would-i-want-stage-before-committing-in-git
'programing' 카테고리의 다른 글
| 제출 jQuery UI 대화 상자 (0) | 2023.10.14 |
|---|---|
| 마리아드비 기둥 매장의 최대 한도는 어떻게 됩니까? (0) | 2023.10.14 |
| Excel, SSRS에서 텍스트로 출력된 번호 필드 (0) | 2023.10.14 |
| md-select는 선택한 값을 설정할 수 없습니다. (0) | 2023.10.14 |
| AngularJS 오류:오류 유형: v2.login이 함수가 아닙니다. (0) | 2023.10.14 |