버전관리 - 로그인 브랜치(Branch)

01.브랜치(Branch)

• 브랜치는 독립적으로 작업을 진행할 수 있도록 합니다.
• 실제로 대부분 규모가 큰 프로젝트를 개발할때 여러 개발자들이 동시에 작업을 진행하기 때문에 브랜치를 여러개로 나눠서 개발 하는 경우가 많습니다.
• 각각의 브랜치는 다른 브랜치의 영향을 받지 않으므로 여러 작업을 동시에 진행할 수 있습니다.
• 각각의 브랜치는 다른 브랜치와 병합(Merge)을 통해 하나의 새로운 브랜치로 모을 수 있습니다.

---

02.새로운 브랜치 생성 방법

2-1.git branch

• 해당 명령어를 통해 현재 프로젝트에서 관리되고 있는 여러 브랜치의 목록을 확인할 수 있습니다.

$ git branch

---

2-2.git branch -a

• 원격 저장소에서 관리되고 있는 브랜치 목록 확인

$ git branch -a

• remotes: 원격 저장소
• origin: 별칭
• master: 브랜치
• 원격 저장소에 origin 이라는 별칭을 가진 master 브랜치가 있다는 뜻 입니다.
• Q키를 누르면 빠져나옵니다.

---

2-3.git branch signin

• signin이라는 브랜치를 생성하는 명령어입니다.

$ git branch signin
$ git branch // 다시 브랜치 목록을 확인

• signin 브랜치가 생성된 것을 확인
• 아직까지는 signin라는 브랜치를 새로 만든것일뿐 master 브랜치에 접속중인 상태입니다.

---

2-4 git checkout signin

• 생성한 signin 브랜치로 이동하는 명령어 입니다.

$ git checkout signin

• Switched to branch 'signin' 이라는 알림 메시지가 자동으로 출력됩니다.
• 초록색 바탕의 영역을 보면 기존의 master 브랜치에서 signin 브랜치로 변경된 것을 확인할 수 있습니다.

---

2-5.새로 만든 브랜치에서 작업 파일 생성하기

• 새로 만든 브랜치에서 작업할 파일을 생성하여 코드를 작성해줍니다.

• 저는 VS code에서 기존의 파일 목록에서 signin 폴더를 만들고 그 폴더안에 index.html 파일을 만들어서 이 html 영역에서 새로운 로그인 기능을 만드는 코드를 작성하였습니다.

---

2-6.git status

• 작업 완료한 파일에서 파일 상태를 확인해줍니다.

$ git status

• 빨간색으로 표시되어 새로 만든signin 폴더가 수정되었음을 알 수 있습니다.

---

2-7.git add .

• 작업 완료한 파일을 추가 해줍니다.

$ git add .
$ git status // 파일 상태를 재확인

• new file 항목에 내가 만든 폴더와 파일이 새롭게 추가된 것을 확인할 수 있습니다.
• 지금 변경사항을 버전으로 만들어서 해당 버전을 추가 해주었습니다.

---

2-8.git commit -m "해당 내용을 대표하는 메시지 내용"

• 수정된 파일을 해당 메시지와 함께 등록합니다.

$ git commit -m "로그인 페이지 시작하기"

---

2-9.git checkout master

• master 브랜치로 이동하는 명령어 입니다.

$ git checkout master

• VS code의 파일 목록에서 signin 브랜치에서 만들었던 signin 폴더가 사라진 것을 확인 할 수 있습니다.
• 이유는 새로운 브랜치를 만들어서 작업을 했기 때문에 실제 master 브랜치와 병합하기 전까지는 signin 브랜치에서 작업했던 내용을은 master 브랜치에 아무런 영향을 주지 않습니다.

$ git checkout signin // signin 브랜치로 이동

• 다시 signin 브랜치로 이동하면 내가 signin 브랜치에서 작업했던 폴더와 파일들을 다시 확인 할 수 있습니다.
• signin 브랜치에서 개발 작업을 진행 하더라도 실제 내가 Netlify로 배포한 사이트에는 아무런 영향을 주지 않습니다.
• 이유는 Netlify 배포 사이트는 내 원격 저장소에서 master 브랜치의 내용을 기반으로 웹 서비스를 제공하기 때문에 master 브랜치와 병합 작업을 하지 않는 이상은 실제 배포 사이트에는 아무런 영향을 주지 않습니다.