[AI 부트캠프] DAY 45 - Git 3

[오늘의 일지]

Git 실시간 강의 - Git branch, 문제 상황 대처법, 미니 프로젝트

[상세 내용]

Git branch

정의

- Git 저장소에서 코드의 복사본을 나타내는 가상의 포인터. 각 브랜치는 코드 베이스의 특정 시점을 가리키며, 각 브랜치에서는 독립적으로 작업할 수 있습니다. 기본적으로 Git 저장소를 만들면 "master" 브랜치가 생성되며, 이 브랜치는 초기 코드 베이스를 나타냅니다. 그러나 프로젝트의 다양한 기능 또는 수정을 위해 새로운 브랜치를 만들 수 있습니다. 각 브랜치는 코드 베이스의 변경 사항을 추적하고, 새로운 커밋을 수용할 수 있습니다. 브랜치를 사용하여 개발자들은 동시에 다양한 작업을 진행하고, 이러한 작업을 추적하고 통합할 수 있습니다. 또한 브랜치를 사용하여 버그 수정, 기능 추가, 실험적인 작업 등을 분리된 환경에서 진행할 수 있습니다. Git 브랜치는 협업과 개발 프로세스를 효과적으로 관리하는 데 필수적인 기능 중 하나입니다.

출처:https://frankgwarman.medium.com/brief-intro-to-git-b52fa5dd2b66

 

- 브랜치 명령어

# 브랜치 확인하기
git branch

# 브랜치 생성하기
git branch <원하는 이름>

# 브랜치 선택 후 사용하기
git switch <브랜치 이름>
git checkouy <브랜치 이름>

# 브랜치 삭제
git branch -d <브랜치 이름>

# 원격 저장소에 있는 브랜치들의 목록
git branch -r
git branch -a

# 브랜치에서 push를 할때는 -u를 사용한다
-u : upstream-set -> branch 'stem' set up to track remote branch 'stem' from 'origin'.

 

- 메인과 브랜치의 통합 상황 3가지

# 메인은 그대로 브랜치가 커밋 되었을 때
git merge <브랜치 이름>

# 브랜치는 그래로 메인이 커밋 되었을 때
git rebase <메인>

# 둘 다 커밋 되었을 때는 충동이 납니다.
그럼 두 개의 파일에서 다른 부분을 보여주고 해결하라고 하는데
원한는 통합 코드로 변경시키고 커밋을 하면 됩니다.

 

Branch models

- Git flow : Git Flow는 Git을 사용하여 소프트웨어 개발 프로젝트를 관리하는 데 사용되는 일련의 브랜치 관리 전략 중 하나입니다. Vincent Driessen이 개발자 커뮤니티에 소개한 Git Flow 모델은 소프트웨어 개발 수명 주기의 다양한 단계와 역할을 관리하며, 기능 추가, 버그 수정, 릴리스 및 유지보수를 효율적으로 처리할 수 있도록 도와줍니다.

출처:https://blog.programster.org/git-workflows

 

- Github flow : GitHub Flow는 소프트웨어 개발 프로세스를 관리하기 위한 Git 기반의 협업 워크플로우 중 하나입니다. GitHub Flow는 GitHub 플랫폼에서 주로 사용되며, 간결하고 유연한 워크플로우를 제공하여 빠르게 소프트웨어를 개발하고 배포할 수 있도록 돕습니다.

출처:https://blog.programster.org/git-workflows

 

- Gitlab flow : GitLab Flow는 GitLab을 사용한 협업 소프트웨어 개발 워크플로우입니다. GitLab은 GitHub과 유사한 기능을 제공하며, 코드 협업, CI/CD, 이슈 관리, 코드 리뷰, 웹 IDE, 프로젝트 관리 등을 통합적으로 제공하는 플랫폼입니다. GitLab Flow는 GitLab을 기반으로 개발, 테스트, 배포, 협업하는 데 사용됩니다.

출처:https://blog.programster.org/git-workflows

 

- 수업에서는 Github flow로 실습

# git bash 환경에서 먼저 브랜치에서 작업 후 push를 합니다.
git push -u origin <브랜치 이름>

# 그런 뒤 github에 가보면 merge를 할 것인지 물어봅니다.
그럼 merge를 하게 되면 바로 수정이됩니다. 

# 수정이 모두 끝났으면 브랜치를 삭제해주는 것이 좋습니다.(로컬이든 github홈페이지든)
git branch -d <브랜치 이름>

 

문제 발생 시 대처법

- 우선 모든 대처 상황은 push를 하지 않았다는 가정하에서 진행됩니다. 강사님도 이미 push 된 commit들은 되도록이면 그냥 코멘트 같은 거로 상황을 설명하고 넘어가는 것이 좋다고 하셨습니다.

 

- 대처 상황 명령어

# Rename : 파일 이름 혹은 위치 수정
$ mv a.md to b.md

# Undo : Working Directory에서 변경사항 취소하기
$ git restore {filename} or .(whole changes)

# Unstaging : Stage의 변경사항(blob) Working directory로 내리기
$ git reset HEAD {filename}

# Unstaging and remove : staging area의 변경사항을 내림과 동시에 삭제
$ git rm -f {filename}

# Edit commit message : 직전 commit message 수정하기
$ git commit --amend

# Edit commit message : 이전 commit message 수정하기
$ git rebase -i <commit>
$ git rebase --continue (rebase 취소: git rebase --abort)

# Reset commit : 없었던 일로 만들기
$ git reset --hard HEAD~{nums of commit}
$ git push -f origin <branch>

# Revert commit : 잘못을 인정하고 특정시점으로 되돌리기
$ git revert --no-commit HEAD~{nums of commit}..
$ git commit
$ git push origin <branch>
# {nums of commit}개의 커밋을 되돌린 후 remote <branch>에 push

 

미니 프로젝트

- 프로젝트의 내용은 팀프로젝트를 할 때 github 홈페이지에서 어떤 식으로 이용하는지 보여주고 실습해 보는 시간을 가졌습니다. github라는 곳이 팀프로젝트를 위해서 운영하기 좋게 여러 가지를 제공한다는 것을 처음 알았는 때 꽤 괜찮은 곳인 걸 다시 한번 느꼈던 시간이었습니다. 비록 주어진 시간이 2시간 밖에 없어서 뭐 제대로 마무리하지 못한 게 아쉬웠지만 다음 팀프로젝트에서 꼭 활용해 보고 싶어 졌습니다.

[마무리]

 오늘은 git 강의의 마지막 날이었습니다. 3일간의 짧으면 짧을 수도 있는 수업을 하루 8시간씩 꽉꽉 담아서 들었는데 정말 알찼던 시간이었다고 생각합니다. 다시 한번 강조하지만 진짜 현업에서 일하게 되거나 팀프로젝트를 할 때 유용하게 쓰일 것 같았습니다. 내일부터는 머신러닝에 대해서 수업을 들을 예정입니다. 이제는 직접적으로 AI와 관련이 있는 파트인 만큼 더욱 집중에서 들을 수 있도록 노력해야 될 거 같습니다.