git의 2 단계 커밋 프로세스 (스테이징)의 이점은 무엇입니까?

174

git을 배우고 있는데 2 단계 커밋 프로세스가 있음을 알았습니다.

git add <files>
git commit

첫 번째 단계는 "스테이징 영역"또는 "인덱스"에 수정 사항을 배치합니다.

내가 관심이있는 것은이 디자인 결정이 내려진 이유와 그 이점이 무엇입니까?

또한 git 사용자 로서이 작업을 수행 git commit -a합니까?

이 기능이없는 bzr (Bazaar)에서 왔을 때 이것을 묻습니다.

version-control git workflows

— 토마스
소스

3

묻기 +1 Tortoise SVN을 사용합니다.이 방법은 동일한 접근 방식을 사용하며 이유를 이해하지 못했습니다.

— DPD

3

준비 영역은 그리 특이하지 않습니다. 예를 들어, TFS는 체크인하기 전에 파일 옆에있는 상자를 확인하거나 선택 취소합니다. 확인 된 파일 만 커밋됩니다. Git과의 차이점은 사용하는 경우 같은 파일git add -p 의 다른 조각을 커밋하지 않고 한 조각의 파일을 커밋하도록 선택할 수 있다는 것 입니다.

— Kyralessa

이 링크 는 여기에 답변 된 내용의 대부분을 요약하고 준비 필요성을 정당화하기 위해 몇 가지 사용 사례를 추가한다는 것을 알았습니다.

— Veverke

2

이 질문은 실제로 이미 답변되었지만, 여기에도 좋은 설명이 있습니다 : stackoverflow.com/questions/4878358/…

— guitar_freak

1

잊지 마세요 git status가능성이 git push. git에 대한 모든 과대 광고 (그리고 GitHub 공유 코드는 훌륭합니다) 부분은 매우 성가시다

— user949300

83

작업을 별도의 커밋으로 나눕니다. 단일 행 수정을 작성하기 위해 파일을 여러 번 열었을 수도 있지만, 동시에 형식이 잘못되었거나 일부 문서가 개선되었거나 관련이없는 다른 수정이 발견되었습니다. 다른 RCS를 사용하면 해당 내용을 기록하거나 메모리에 커밋하고 수정 사항을 완료하고 커밋 한 다음 다른 항목을 수정하기 위해 돌아갑니다 (또는 관련이없는 항목으로 진흙 공을 커밋하십시오) . 힘내으로 당신은 한 번에 그것의 모든 문제를 해결하고, 단계 +와 별도로 한 줄을 커밋 git add -i또는 git-gui.

빌드를 중단하지 마십시오. 복잡한 수정 작업 중입니다. 그래서 당신은 다른 것들을 시도합니다. 어떤 것들은 다른 것보다 더 잘 작동하고 어떤 것들은 부러 뜨립니다. Git을 사용하면 수정 작업이 개선 checkout되었을 때 작업을 수행하고 수정 작업이 수행되지 않을 때 작업을 더 조정할 수 있습니다. 편집기의 실행 취소 기능에 의존 할 필요가 없으며 checkout파일 단위 대신 전체 리포지토리 및 파일 수준 실수 (예 : 커밋되지 않은 파일 제거 또는 저장 후 닫기 등) 잘못 수정하면 많은 작업 손실이 발생하지 않습니다.

— l0b0
소스

3

이 기능이없는 DVCS (bzr)에서 온 것은 현재 편집자의 "실행 취소"버퍼, "revert <file>"명령 및 선택적 커밋 ( " 커밋 <file> "). git 의이 기능과 같은 소리는보다 체계적 일 수 있습니다.

— thomasrutter

1

"다른 RCS"에 관해서는 반드시 그런 것은 아닙니다. 실제로 패치를 사용하여 Mercurial에서 동일한 기능을 수행 할 수 있습니다 .

— Lucio Paiva

1

두 번째 요점은 @ l0b0입니다. 단일 단계 커밋이있는 경우 변경 사항 (git add와 함께 사용)을 커밋으로 직접 커밋했을 수 있습니다. 당신이 뭔가 잘못한 것을 발견했다면, 당신은 커밋을 삭제하고 커밋을하기 전의 위치로 돌아 왔을 것입니다. 스테이징 개념을 사용하면 그렇게하는 것이 아니라 더 많은 복잡성을 추가 할 수 있습니까?

— alpha_989

첫 번째 요점은 지금까지는 사용하지 않았지만 의미가 있습니다. 이론적으로 왜 git add -i단일 스테이지 커밋으로 무언가를 할 수 없습니까? 단일 기능과 관련된 많은 파일 (또는 파일 내 줄)을 선택하고 커밋을 수행합니다. 그런 다음 돌아와서 다른 기능과 관련된 두 번째 커밋을 수행합니다.

— alpha_989

@thomasrutter, 귀하의 진술에서, 준비 영역이 "수동 실행 취소 지점"을 생성한다고 제안하는 것 같습니다. 지속적 실행 취소 기능이있는 VIM에서는 무제한 히스토리를 매우 안정적으로 얻을 수 있습니다. 이것은 git-branch유형 형식 으로 자동 추적됩니다 ( jovicailic.org/2017/04/vim-persistent-undo ). 또한 일반 모드로 전환 할 때마다 실행 취소 기록이 자동으로 추적됩니다. 따라서 "수동 실행 취소 지점"을 작성해야하는 정신적 부담이 줄어 듭니다. 왜 편집기 "실행 취소"버퍼를 사용하는 것이 체계적이지 않습니까?

— alpha_989

65

나를위한 이점 중 하나는 파일을 점진적으로 "추가"하는 기능입니다. 커밋하기 전에 각 파일을 검토합니다. 파일이 검토되면 추가합니다. I git status또는 git diff, git은 수정되었지만 아직 추가되지 않은 파일 만 표시합니다. 모든 파일을 검토하고 추가하면 커밋 할 수 있습니다.

예, 준비 영역이 매우 유용합니다.

그리고, 나는 결코 사용하지 않습니다 git commit -a. 그러나 나는 종종을 사용 git add -u합니다. 이렇게하면 커밋 할 내용을 시각화 할 수 있습니다.

— 데이비드
소스

2

바로 그거죠. 장점은 자신이 출근하는 것을 정확하게 제어 할 수 있다는 것입니다.

— Josh K

하나의 파일을 여러 번 스테이징하면 어떻게됩니까? 준비 영역에서 "병합"됩니까?

— m4l490n

21

이점은 매우 간단합니다. 커밋 할 파일을 완전히 제어 할 수 있습니다. 그 문제에 대해 커밋하려는 라인git add -p 을 제어하는 데 사용할 수 있습니다 .

— 레인 헨리 치
소스

2

나는 항상 이것을하는 방법에 대해 궁금했습니다. .gitignorelines커밋을 유지하고 손상되지 않은 개별 행을 로컬로 변경할 수 있도록 파일이 있었으면 좋겠습니다 .

— alex grey

3

@ReinHenrichs, 각 개발자가 변경해야하는 구성 파일에 대해 생각해보십시오.

— Ian

1

@Ian 따라서 파일의 일부가 자주 변경되지 않고 공유되고 파일의 일부가 호환되지 않는 방식으로 자주 변경되고 공유되지 않습니까? 이 잘못된 일치를 지원하는 것은 확실히 반 기능처럼 들립니다.

— Rein Henrichs

1

@ReinHenrichs, 예. 파일에 데이터베이스 서버의 이름이 있고 각 개발자가 자신의 데이터베이스를 가지고있을 때 매우 일반적입니다.

— Ian

4

@Ian 문제는 실제로 응용 프로그램의 구성으로 간주되는 파일이 일부 시스템 / dev 특정 구성을 포함하고 있다는 것입니다. 내가 아는 모든 구성 시스템을 사용하면 여러 구성 파일로 분할 할 수 있습니다. 예를 들어 app.conf공유하려는 항목 이 들어있는 파일을 가지고 db.conf있고 .gitignore 목록에 넣은 파일이 있습니다. 문제 해결됨. 독점적 인 것을 사용하는 경우 실제로 매우 간단한 것을 얻는 것이 좋습니다. 또는 사전 빌드 이벤트에서 전처리기를 통해 배치하십시오. 많은 솔루션이 있습니다.

— Aidiakapi

1

내가 좋아하는 이점 중 하나는 변경의 일부를 커밋 할 수 있다는 것입니다. 즉, git add -e를 사용합니다. 때때로 자주 커밋하지 않고 git add -e 명령을 사용하면 변경 사항을 어느 정도 해결할 수 있습니다.

— Leed25d
소스