Git & Sourcetree - Git에서의 Working Copy와 Index

목표

 

버전관리 프로그램인 Sourcetree를 사용하면서, File status에서 보여지는 각 파일들 앞의 아이콘이 무엇을 의미하는지 이해하도록 합니다. 또한 아래 과정을 통해서 Git에서의 Working Copy와 Index(Staging Area)를 학습합니다.

 

 

 

1. Local Repository에 또 다른 텍스트 파일 추가, 기존의 test 파일 수정하기

 

• 우선, 이전 포스팅에서와 했던 것과 같이 해당 Repository에 README 파일을 새로 추가합니다.
• Local Repository안에 추가해둔 test.txt 파일을 다시 한 번 수정하도록 합니다.
• 위의 작업을 마친 후 Sourcetree의 File Status는 다음과 같습니다.

위의 이미지를 보시면 방금 추가된 파일과 test 파일 앞에 아이콘이 서로 다른 것을 확인할 수 있습니다. 아이콘이 의미하는 바는 두개의 파일이 Git의 입장에서 서로 다른 파일임을 의미합니다. test 파일은 Git에 의해 추적되고 있는 파일인 것을 의미하고, 방금 추가한 파일은 아직 Git에게 버전관리를 부탁하기 전 상태를 의미합니다. 그래서 Git은 사용자가 인지할 수 있도록 다른 로고를 부여하게 됩니다.

 

 

 

2. README.md 파일 Commit 하고 다시 수정해보기

 

• 아이콘의 상태를 확인해보기 위해 방금 추가한 README 파일을 먼저 Commit하도록 합니다.
• Commit후 해당 파일을 다시 수정해보도록 합니다.
• 수정된 후의 File status를 다시 확인해보면 아래 그림과 같습니다.

각 파일앞의 아이콘을 확인해보면 기존의 파일과 추가된 파일의 아이콘이 같아진 걸 확인할 수 있습니다. 이제 README 파일도 Git에 의해 관리되는 파일인 것을 의미합니다. 이것을 통해 주목해야될 것은 새로운 파일을 추가하면 사용자가 Commit하기 전(최초의 버전을 만들기 전)까지는 Git이 관리해주지 않는다라는 사실을 기억하도록 해야합니다.

 

 

 

3. 변경된 복수의 파일을 Commit 해보기

 

• 두개의 파일을 동시에 Commit 하여 무엇을 의미하는지 확인해봅니다.

방금 Commit 한 버전을 클릭해보면, 아래 README 파일과 test.txt파일의 변경점이 같은 버전으로 묶여있는 것을 확인할 수 있습니다. 즉, 하나의 버전에는 여러개의 변경사항이 포함된다는 것을 알 수 있습니다.

 

 

 

4. test.txt 파일만 수정하여 Commit 하기

 

• 복수의 파일을 버전으로 관리하던 중, 하나의 파일만 수정해보도록 합니다.

Commit한 파일에 대해서만 변경사항을 저장하여 관리하게 됩니다. 우리는 변경된 모든 파일을 하나의 버전으로 놓지않고, 각각의 변경사항 중에서 필요한 파일들, 완결된 파일들, 연관되어 있는 파일들만 그룹화해서 하나의 버전으로 만들 수 있는 것을 확인할 수 있습니다.

 

 

 

5. 전 과정을 다시 이해해보기

 

• 변경사항을 Commit하기 앞서 체크상태를 구분하여 볼 수 있게 설정이 되어 있지 않다면 아래와 같이 Split view staging을 클릭하여 구분해 볼 수 있습니다. 

Git에서는 수정된 내역들이 나타내는 공간(Unstaged files)을 Working Copy라고 말하고, 체크하는 행위를 Add라고 합니다. 또한 체크된 상태의 공간(Staged files)을 Index와 Staging area라고 부릅니다. 체크된 변경사항들이 Commit된 후의 각각의 버전들을 저장되어있는 공간을 Repository라고 부릅니다.