몇번이나 git으로 작업을 하는데도 기본적인 지식을 반복하지 않으면 잊게되는 것 같다.
그래서 git workFlow에 대해 마음먹고 정리한다.

학습목표

1. 혼자 작업하는 workflow
2. 함께 작업하는 workflow
3. Git의 3가지 영역 및 상태를 이해한다.
4. 충돌이 발생한 경우 해결한다.

---

Git의 3가지 영역 및 상태 및 기본 명령어

1. Git의 영역과 기본 명령어

git의 주요 기능은 3가지로 설명할 수 있다.

• 버전 관리
• 백업
• 협업

즉, Git을 통해 로컬에서 파일의 버전을 관리할 수 있으며, 파일을 온라인으로 업로드하면 협업 및 백업 기능을 활용할 수 있다.

Git의 영역은 Git으로 관리하는 파일이 위치하는 영역을 의미하며, 물리적인 특정 위치가 아닌 논리적이고 개념적인 영역이다.

git의 영역은 크게 온라인과 로컬로 나뉜다.

• 온라인: Remote repository(원격 저장소)
• 로컬 : Work space(작업 공간), Staging area(스테이징 영역), Local repository(지역 저장소)

2. Git으로 파일 관리를 시작: git init

git init

“Initialized empty Git Repository in ~”는 git init이 성공했을 때 나타나는 문구이다.

2.1 git 초기화로 파일 관리를 시작하면 기본 브랜치가 생성된다.

• 보통 master라는 이름으로 생성된다.
• 그러나 master라는 표현이 다소 인종차별적인 뉘앙스를 가질 수 있어 대부분 기본 브랜치는 main으로 많이 사용한다.
• 따라서, git init을 입력했을 때 생성되는 기본 브랜치의 이름을 main으로 변경하기 위해선 아래의 명령어를 사용하면 된다.

git config --global init.defaultBranch main
git branch -m main

2.2 .git 디렉토리 생성

• git init 후, .git 디렉토리가 생성된다. 그러나 ls -l을 입력해도 .git 디렉토리를 확인할 수 없다.
• 디렉토리나 파일 이름의 맨 앞에 .이 붙으면 해당 디렉토리 또는 파일이 숨김 처리 되어 일반적인 ls명령어로는 확인할 수 없다.
• 만일 ls 명령어 옵션으로 -a를 붙여주면 숨김 처리된 디렉토리 및 파일을 확인할 수 있다.

ls -al

• Git은 파일을 관리할 때 필요한 모든 정보들을 .git 디렉토리에 보관한다.
• 따라서, .git 디렉토리를 실수로 삭제하면 Git 명령어가 제대로 동작하지 않게 되므로, .git 디렉토리는 감춰진 상태로 존재하도록 설계되어있다.

2.3 Work space

Work space는 Git의 세 가지 영역 중 하나로, Working tree 또는 Work tree라고도 하며, 우리가 눈으로 볼 수 있는 디렉토리 자체를 의미한다.

Git은 Work space를 자동으로 스캔한다. Git이 Work space를 스캔하다가 무언가 변경된 사항을 발견하면 사용자에게 해당 사항을 알려주고, 어떤 행위를 취해야 하는지 적절한 명령어 및 동작을 알려준다.

Work space는 git init을 입력한 직후, 다른 어떠한 Git 명령어도 입력하지 않은 상태의 파일들이 존재하는 영역이다.

3. 파일들의 상태를 확인하기 : git status

• git status 는 git으로 관리되고 있는 파일들의 상태를 관리하는 명령어이다.
  

• On branch main
  - 현재 브랜치는 main 브랜치이다.
  - 위의 [2.1. 기본 브랜치 이름 변경하기]에서 바꿔둔 대로 브랜치 이름이 main으로 붙여져 있다.

• No commits yet
  - 아직 커밋을 하지 않았다는 의미

• Untracked files: ~
  - Untracked는 Git의 관리하에 있는 파일이 가질 수 있는 상태 중 하나이다.

• (use “git add <file>…” to include in what will be committed)
  - git add 파일_이름을 입력하면 커밋될 것들에 해당 파일을 포함시킬 수 있다는 의미이다.

• nothing added to commit but untracked files present (use "git add" to track)
  - 아직 add된 파일들이 없으며 Untracked 상태의 파일이 존재하니, git add 명령어를 사용하라고 안내되고 있다.
  

3.1 파일의 상태 Tracked(Unmodified, Modified, Staged) / Untracked

⭐️ Git의 관리하에 있는 파일들의 상태는 크게 Tracked와 Untracked로 나뉘며, Tracked는 다시 Unmodified, Modified, Staged로 나뉜다.

• Untracked : git에 의해 파일의 상태가 추적되고 있지 않은 상태, commit이라는 과정을 거치면 Tracked 상태로 바뀜
• Tracked : git에 의해 파일의 상태가 추적되고 있음
  • Unmodified: 파일의 수정이 Git에 의해 감지되지 않은 상태
    • Modified: 파일의 수정이 Git에 의해 감지된 상태
    • Staged: 파일이 Staging area에 존재하는 상태
      - 기본적으로, Commit을 해야 Tracked 상태로 변경될 수 있지만, Commit을 하지 않은 파일도 예외적으로 Staged 상태를 가질 수 있다.

다시 말하면, Tracked 상태인 파일들은 수정되었을 때 Git이 파일의 변경 내용을 감지하지만, Untracked 상태인 파일들은 파일의 내용을 변경하여도 Git이 파일의 내용 변경을 감지하지 못한다는 것이다.

3.2 Staging area

아래의 출력 결과를 살펴보자.
“what will be committed"라는 문구를 주목하면, 이는 Staging area를 가리킨다고 할 수 있다.

Staging area란,
- Local repository에 저장할 파일들이 임시로 대기하는 영역을 의미한다.
- 일반적으로 Git을 활용하여 작업을 할 때는 Work space에서 작업을 마친 파일을 Staging area로 옮겨서 모아두고, 추후 어느 정도의 단위 작업이 끝나면 Staging area에 모인 파일들을 한 번에 Local repository로 저장한다.

4. Staging area로 파일을 이동시키기 : git add

• 보통 프로젝트나 실무에서는 개별 파일을 스테이징하는 경우도 있지만, 디렉토리 내의 전체 파일을 스테이징 하는 경우도 있다.
• 이러한 경우에는 모든 파일의 이름을 git add 명령어 뒤에 나열하지 말고, git add .을 입력하면 된다.
• git add .를 입력하면 현재 디렉토리 내의 모든 파일이 스테이징 된다.
• 명령어를 입력해도 아무 일이 발생하지 않는 이유는 리눅스가 어떤 명령어를 성공하면 침묵하기 때문이다.
• 다시 git status를 살펴보자.
  
• Changes to be committed: ~
  - 변화가 감지되었으며, 아래의 파일들을 Commit 할 수 있음을 의미한다.
• (use "git rm --cached <file>..." to unstage)
  - 해당 명령어를 입력하면 새롭게 생성하여 스테이징한 파일을 다시 Work space로 되돌릴 수 있다.
  

5. 파일을 Local repository에 저장하고 버전을 기록하기 : git commit

• git add를 통해 스테이징까지 마쳤다면, 이제 Commit을 할 수 있다.
• Commit 이란,
  • Local repository에 파일을 저장하는 행위를 가리키며,
  • 파일을 Local repository에 저장함과 동시에 파일의 버전을 기록한다.

앞서, 우리는 git의 핵심 기능 중 하나가 버전 관리라는 것을 살펴보았다. git commit명령어는 바로 버전 관리에 사용되는 핵심적인 명령어다.

[심화]
보통 커밋 메시지는 조직마다 일정한 룰이 정해져 있거나 모범적인 사례를 따른다. 커밋 메시지를 작성할 때의 보편적인 룰이나 관례에 대해서는 아래의 키워드로 검색해서 스스로 살펴보기.

commit message convention, commit message rule …

git commit명령어를 입력하면 위와같은 안내가 보인다.
출력 결과에서 중요한 부분은,

• commit message convention, commit message rule …
  • 커밋을 실시한 브랜치와 커밋 해시의 앞 부분, 커밋 메세지가 보인다.
  • 커밋 해시란 각 커밋마다 부여되는 고유한 id이다.
  • ex) 커밋 해시: 868dc6b
• 1 file changed, 1 insertion(+)
  • 변경된 내용을 보여준다. → 즉, 이제 파일이 Tracked 상태로 변화되었음을 의미한다.

6. 작업물을 Remote repository로 업로드하기 : git push

작업물을 Remote repository로 업로드한다는 것은 온라인 저장소에 작업물을 백업하고, 다른 사람과 공유할 수 있게 하는 것을 의미한다. 즉, Git의 핵심 기능 중 백업과 협업에 있어 핵심이 된다.

• git hub에서 git repository를 생성한다.
• git remote --v : 명령어를 입력한 위치의 Local Repository와 연결된 Remote repository가 있는지 확인하는 명령어이다.
• git hub에서 생성된 repository의 URL을 복사한다.
  
• 예를 들어, https://github.com/git_practice.git이라는 URL을 가진 Remote repository에 origin이라는 이름을 붙이고자 한다면 아래와 같이 명령어를 입력한다.
  git remote add origin https://github.com/git_practice.git
• remote가 잘 되어있는 확인하려면 remote --v명령어를 통해 확인할 수 있는데 출력화면의 origin 은 remote repository로 업로드 할 때 사용하는 별칭과 URL을 의미한다.

origin (주소) (fetch)
origin (주소) (push)

여기까지 잘 따라왔다면, git push를 통해 이제 본격적으로 작업물을 업로드 해보자!!!
git push란, 작업물을 Remote repository에 업로드하는 행위다.

git push origin main

이렇게 하면 git hub 홈페이지의 repository에서 push된 파일을 확인 할 수 있다.
지금까지의 내용을 도식화 하면 다음과 같다.

혼자 작업하는 workflow

함께 작업하는 workflow

아래의 명령어를 통해 다른사람의 Remote Repository에 있는 작업 내용을 받아올 수 있다.
받아오는 내용은 자동으로 merge 된다.

git pull origin main

충돌이 발생한 경우 해결한다.

충돌이 발생한 파일을 열어 보면 어떤 부분에서 충돌이 발생한 것인지 확인할 수 있다. 그리고 충돌이 일어난 부분은 하나하나 직접 확인 후 수정이 필요하다.

• IDE에 따라 아래의 화면과 다를 수 있다. 클릭 버튼이 생기지 않는다면 충돌이 일어난 부분을 직접 수정하여 해결할 수 있다.

• Accept Current Change를 클릭해서 내가 수정한 내용으로 파일에 반영할 수 있다.
• Accept Incoming Change를 클릭해서 Remote Repository의 내용으로 파일에 반영할 수도 있다.
• Accept Both Changes는 변경 사항 모두를 반영한다.

위 4가지 옵션 이외에도 직접 파일을 수정해서 반영하는 방법도 있다.

수정을 마치면 병합 커밋(merge commit)을 생성해 주기 위해서 파일을 staging area로 추가해야 한다.
충돌한 파일 수정을 완료했다면 Remote Repository에 업로드하기 위해서 staging area에 파일을 추가한다.

Merge commit은 자동으로 Commit 메시지가 생성된다. (물론 메시지를 수정할 수도 있다.)
그리고 Remote Repository에 Push 한다면 다음 화면과 같이 Merge branch ‘master’ of 라는 commit 메시지가 기록된다.

Remote Repository로 push가 완료되었다!
끝!!