Git에서 커밋하기 전에 스테이지를 원하는 이유는 무엇입니까?

Git에서 커밋하기 전에 스테이지를 원하는 이유는 무엇입니까?

---

저는 버전 관리가 처음이고 "커밋"이 기본적으로 작업중인 새 '현재'버전을 업데이트하는 동안 백업을 생성한다는 것을 이해합니다.

내가 이해하지 못하는 것은 실제적인 관점에서 스테이징이 무엇인지입니다. 이름으로 만 존재하는 것을 준비하는 것입니까, 아니면 목적에 부합합니까? 커밋하면 어쨌든 모든 것을 커밋 할 것입니다.

편집 : 용어를 혼동 할 수 있다고 생각합니다. '스테이지'파일이 '추적'파일과 동일한가요?

---

커밋하면 인덱스 ( "스테이징 된"파일)의 변경 사항 만 커밋됩니다. 이것에 대한 많은 용도가 있지만 가장 분명한 것은 작업 변경 사항을 작은 독립된 조각으로 나누는 것입니다. 기능을 구현하는 동안 버그를 수정했을 수 있습니다. git add해당 파일 만 (또는 파일의 git add -p일부만 추가 할 수 있습니다 !) 다른 모든 것을 커밋하기 전에 해당 버그 수정을 커밋 할 수 있습니다. 사용하는 경우 커밋 직전에 모든 것을 git commit -a강제하는 것 add입니다. -a스테이징 파일을 활용 하려면 사용하지 마십시오 .

--cachedto many 명령을 사용하여 준비된 파일을 중간 작업 복사본으로 취급 할 수도 있습니다 . 예를 git diff --cached들어은 스테이지가 어떻게 다른지 보여 주므로 HEAD다른 작업 변경 사항을 혼합하지 않고도 커밋하려는 내용을 확인할 수 있습니다.

---

• 스테이징 영역은 커밋을 더 작게 만드는 제어를 제공합니다. 코드에서 논리적으로 하나만 변경하고 변경된 파일을 스테이징 영역에 추가하고 마지막으로 변경 사항이 잘못된 경우 이전 커밋으로 체크 아웃하거나 변경 사항을 커밋하면 작업을 더 작은 작업으로 분할하고 더 작게 커밋 할 수있는 유연성을 제공합니다. 변화. 준비 영역을 사용하면 작은 작업에 더 쉽게 집중할 수 있습니다.
• 또한 휴식을 취하고 휴식을 취하기 전에 얼마나 많은 일을했는지 ​​잊어 버리는 제안을 제공합니다. 하나의 논리적 변경을 수행하기 위해 세 개의 파일을 변경해야하고 첫 번째 파일을 변경했으며 다른 변경을 시작할 때까지 긴 휴식이 필요하다고 가정하십시오. 이 순간에는 커밋 할 수 없으며 어떤 파일을 사용했는지 추적하여 돌아온 후 얼마나 많은 작업이 수행되었는지 기억할 필요가 없습니다. 따라서 파일을 준비 영역에 추가하면 작업이 저장됩니다. 돌아 오면 git diff --staged변경 한 파일과 위치를 확인하고 다른 변경을 시작하십시오.

---

스테이징의 실용적인 목적 중 하나는 파일 커밋의 논리적 분리입니다.

스테이징을 통해 파일 / 작업 디렉토리를 계속 편집하고 준비가되었다고 생각할 때 부분적으로 커밋을 수행 할 수 있으므로 논리적으로 관련이없는 편집을 위해 별도의 단계를 사용할 수 있습니다.

당신이 4 개 파일이 있다고 가정 fileA.html, fileB.html, fileC.html와 fileD.html. 당신은 모든 4 개 파일을 변경하고 커밋 할 준비가되어 있지만,의 변화 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"

---

자식 명령의 사용을 이해하는 것이 더 쉽습니다 add그리고 commit당신이 상상하는 경우 로그 파일은 Github에서의 저장소에 유지되고. 일반적인 프로젝트의 로그 파일은 다음과 같습니다.

---------------- 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냅니다. 따라서 하루 기록의 모든 것은 그들 사이에서 일어나는 일과 일치합니다. 매일 몇 개의 파일을 변경해야하는 하나 이상의 논리적 작업 이 있습니다. 해당 작업 중에 편집 된 파일은 색인에 나열됩니다.

이러한 각 하위 작업 (여기서 작업 A 및 작업 B)은 개별 커밋입니다. 이 git add명령은 '변경된 파일 색인'목록에 파일을 추가합니다. 이 프로세스를 스테이징이라고도합니다. 이 git commit명령은 사용자 지정 메시지와 함께 변경 사항 및 해당 인덱스 목록을 기록 / 마무리합니다.

여전히 저장소의 로컬 복사본 만 변경하고 Github의 복사본은 변경하지 않습니다. 그런 다음 'git push'를 수행 할 때만 기록 된 모든 변경 사항을 각 커밋에 대한 인덱스 파일과 함께 수행하고 기본 저장소 (Github)에 기록됩니다.

예를 들어 가상 로그 파일에서 두 번째 항목을 얻으려면 다음을 수행해야합니다.

git pull
# Make changes to these files
git add File3 File4
# Verify changes, run tests etc..
git commit -m 'Correct typos'
git push

In a nutshell, git add and git commit lets you break down a change to the main repository into systematic logical sub-changes. As other answers and comments have pointed out, there are ofcourse many more uses to them. However, this is one of the most common usages and a driving principle behind Git being a multi-stage revision control system unlike other popular ones like Svn.

---

Staging area helps us craft the commits with greater flexibility. By crafting, I mean breaking up the commits into logical units. This is very crucial if you want a maintainable software. The most obvious way you can achieve this:

You can work on multiple features/bugs in a single working directory and still craft meaningful commits. Having a single working directory which contains all of our active work is also very convenient. (This can be done without a staging area, only as long as the changes don't ever overlap a file. And you also have the added responsibility of manually tracking whether they overlap)

You can find more examples here: Uses of Index

And the best part is, the advantages do not stop with this list of workflows. If a unique workflow does come up, you can be almost sure that staging area will help you out.

---

I see the point on using stage to make commits smaller as mentioned by @Ben Jackson and @Tapashee Tabassum Urmi and sometimes I use it for that purpose, but I mainly use it to make my commits larger! here is my point:

Say I want to add a small feature which require several smaller steps. I don't see any point in having a separate commit for smaller steps and flooding my timeline. However I want to save each step and go back if necessary,

I simply stage the smaller steps on top of each other and when I feel it is worthy of a commit, I commit. This way I remove the unnecessary commits from the timeline yet able to undo(checkout) the last step.

I see other ways for doing this (simplifying the git history) which you might use depending on your preference:

1. git amend (which changes your last commit) which is not something you want for this specific purpose (I see it mostly as doing a bad commit and then fixing it)
2. git rebase, which is an afterthought and can cause serious problems for you and others who use your repository.
3. creating a temporary branch, merge and then delete it afterwards(which is also a good option, requires more steps but gives your more control)

참고URL : https://stackoverflow.com/questions/4878358/why-would-i-want-stage-before-committing-in-git