TIL - 240411 GIT & GITHUB

First-Word

git : 버전 관리하는 프로그램

github : 외부 컴퓨터, 프로그램을 올리는 외부 프로그램

commit : 프로젝트 디렉토리의 특정 모습을 하나의 버전으로 남기는 행위 또 결과

Repository : 커밋이 저장되는 저장소

오픈 소스 : 프로그램의 소스 코드가 대중에 공개된 상태

커밋 히스토리 : 지금까지 해온 커밋

Today I Lean

Git

깃은 내부적으로 크게 3가지 종류의 작업 영역을 두고 동작합니다.

1. Working directory : 작업하는 영역의 프로젝트 디렉토리
2. staging area : git add를 한 파일들이 존재하는 영역. 커밋을 하게 되면 이 곳에 있는 파일들 만 커밋에 반영됨
3. repository : 변경 이력들이 저장되어 있는 영역.

<aside> 🛠 working directory에서 작업을 하고, 작업한 파일들을 git add를 하여 커밋하면 staging area에 있던 파일들이 repository에 저장됩니다.

</aside>

커멘드를 좀 더 자세히 알고 싶거나 의미에 대해 알고 싶어요!!

git help (커맨드), man git-커멘드 를 사용하여 공식 메뉴얼 중에서 해당 커멘드에 관한 내용을 확인하면됩니다! 공식 메뉴얼을 확인한 뒤 메뉴얼 화면에서 나가고 싶다면 q(quit, 나가다)를 입력하면 됩니다.

오픈 소스 프로젝트?

GitHub에는 훌륭한 프로젝트들이 많습니다. 그리고 이런 프로젝트는 대부분 그 소스 코드가 공개되어 있는데 이러한 프로젝트를 ‘오픈 소스 프로젝트(open source project)’라고 합니다.

오픈 소스라고 해서 사용할 때 아무런 제약이 없는 것은 아니고 다양한 종류의 라이센스들이 있습니다.

오픈 소스 프로젝트의 장단점

장점

• 무료로 사용할 수 있다.
• 여러 개발자들이 참여하기 때문에 폐쇄적으로 코드를 관리할 때보다 코드의 신뢰도가 더 높다.(이 부분은 사람마다 의견이 다를 수 있습니다)
• 오픈 소스 프로젝트에 참여 중인 다른 개발자들에게 질문을 할 수 있다.
• 어떤 프로그램을 개발할 때 특정 분야에서 사실상 표준처럼 사용되는 오픈 소스 프로그램을 많이 활용할수록 전체 개발 속도를 단축시킬 수 있다.

단점

• 참여자 수가 많지 않거나, 참여자의 실력이 좋지 않으면 소스 코드의 신뢰성을 보장하기 어렵다.
• 해당 오픈 소스를 사용해서 문제가 생겼을 때 보상을 해주거나, 책임을 질 주체가 없다.

README.md

• 이 프로젝트가 어떤 프로젝트인지 설명
• 프로그램의 주요 사용법을 알려줌
• 프로그램을 실행시키려면 어떤 사전 작업이 필요한지 알려줌

리드미 파일에는 보통 이런 내용이 적혀있습니다. 이러한 내용을 좀 더 가독성있고 예쁘게 꾸미려면 markdown을 이용하여 꾸며주면 됩니다.

markdown이란 특정 규칙에 맞게, 간단한 텍스트만으로 어떤 표시를 해두면, 그것이 자동으로 HTML 태그로 전환되도록 약속된 문법입니다. 그래서 단지 텍스트만으로도 내용의 디자인을 예쁘게 만들 수 있습니다.

커밋 (commit)

커밋은 Git에서 매우 중요한 개념입니다. 커밋은 작업 내용의 '스냅샷'을 의미하며, 한번 커밋하면 이력이 남습니다. 이런 특성 덕분에 문제가 발생했을 때 이전 상태로 쉽게 되돌릴 수 있습니다. 한마디로 말하자면 커밋은 Git에서 관리하는 가장 작은 단위의 버전이라고 할 수 있습니다.

• 질문: 커밋과 푸시에 대해서 비교하면서 설명해 주실 수 있을까요?
  • 커밋과 푸시는 완전히 다른 동작입니다. 커밋은 로컬 저장소에 변경 내역을 저장하는 동작이며, 푸시는 이 변경 내역을 원격 저장소에 업로드하는 동작입니다.

커밋 생성, 커밋 메시지 작성 가이드 라인

1. 커밋 메시지 작성 가이드라인
   1. 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두세요.
      • Git에서 공식적으로 권장하는 사항입니다.
   2. 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 마세요.
   3. 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성하세요.
   4. 커밋 메시지의 제목은 명령조로 작성하세요.
   5. 커밋의 상세 내용에는 이런 걸 적으면 좋습니다.
      • 왜 커밋을 했는지
      • 어떤 문제가 있었고
      • 적용한 해결책이 어떤 효과를 가지는지
   6. 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 작성하세요.
2. 커밋할 때 알아야할 가이드 라인
3. 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기도록 하세요. 다양하게 수정을 하고나서 하나의 커밋으로 남기는 것은 좋지 않습니다. 하나의 커밋이 하나의 사실만을 갖고 있어야 나중에 이해하기 쉽습니다.
4. 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 하도록 하세요. 나중에 동료 개발자가 특정 커밋의 코드로 실행했을 때 에러가 발생한다면 혼란을 줄 수 있습니다.
5. 나중에 다시 봤을 때 이해하는데 어려움이 없도록 해야합니다.
6. 다른 동료 개발자와 협업하는 데 방해가 되지 않도록 해야합니다..

브랜치 (branch)

Git의 브랜치는 독립적으로 작업을 진행하고 그 결과를 저장할 수 있는 개별적인 흐름을 의미합니다. 브랜치를 사용하면, 서로 다른 작업을 별도로 진행하고 나중에 하나의 코드베이스로 병합할 수 있습니다. 이는 여러 개발자가 동시에 다양한 작업을 진행할 때 매우 유용합니다.

• 질문: 브랜치를 버전이라고 말할 수 있을까요?
  • 브랜치는 특정 커밋을 가리키는 참조(reference)로, 이를 통해 우리는 여러 개의 작업을 독립적으로 진행할 수 있습니다. 브랜치가 특정 '버전'을 가리키고 있다고 볼 수 있습니다.
  • 하지만, 브랜치 자체가 '버전'이나 '스냅샷'이 아니라는 것이 중요합니다. 즉, 브랜치는 단지 '스냅샷'인 커밋을 가리키는 참조일 뿐입니다. 이 브랜치를 통해 우리는 서로 다른 커밋, 즉 서로 다른 '버전'이나 '스냅샷'을 쉽게 전환할 수 있습니다.

Origin 이란?

git remote add origin https://github.com/kyuri-dev/Math_Box.git

 

origin은 ‘근원’, ‘기원’이라는 뜻을 가집니다. 아마도 다른 사람의 리모트 레포지토리를 자신의 컴퓨터로 가져와서 작업을 하는 사람의 입장에서는 리모트 레포지토리가 프로젝트의 근원이 되는 존재이기 때문에 그런 관습이 생긴 것으로 추측됩니다.

일반적인 git의 작업 흐름

git pull → git checkout [브랜치 이름] → git add . → git commit → git push

Organization

Organization 기능을 활용하면 Front-end와 Back-end 등의 다양한 영역으로 나눠진 저장소를 한데 모아, 프로젝트 관리를 간소화할 수 있습니다. 이는 팀원들 간의 협업을 더욱 원활하게 하고, 프로젝트의 통합 관리를 가능하게 합니다.

Organization 내에서는 Projects라는 기능을 이용할 수 있습니다. Projects는 할 일 목록 등을 관리하는 도구로, 이를 통해 프로젝트의 진행 상황을 시각화하고 작업의 우선순위를 정할 수 있습니다. 이 기능을 활용하면, 팀원들이 작업 항목과 진행 상황을 빠르게 파악하며, 효과적인 협업을 실현할 수 있습니다. 그러나 Projects를 최대한 활용하기 위해서는 이슈 관리 등의 기본적인 협업 지식이 필요할 수 있습니다.

Issues

Issues는 버그 추적과 프로젝트 관련 토론을 위한 중요한 기능입니다. 사용자들은 이슈를 작성하여 버그 리포트, 기능 요청 등을 다른 사용자들과 공유하고 토론할 수 있습니다. 이슈를 통해 프로젝트의 문제를 추적하고 해결할 수 있으며, 팀원들과의 협업과 의사소통을 강화할 수 있습니다.

Pull Requests

Pull Request는 다른 사용자들에게 자신이 작업한 코드 변경 사항을 검토하고 병합해 달라고 요청하는 기능입니다. 다른 사용자들은 Pull Request를 검토하고 의견을 주고받을 수 있으며, 프로젝트에 기여할 수 있습니다. Pull Request는 코드 변경의 품질을 개선하고 버그를 예방하는 데에 중요한 역할을 합니다. 이를 통해 다른 사람들과의 협업과 코드 리뷰를 통한 품질 향상을 이끌어낼 수 있습니다.

개인 프로젝트

개인 프로젝트에서도 PR을 활용하면 자신이 작성한 코드를 체계적으로 검토하고 문서화하는데 큰 도움이 됩니다. PR을 통해 코드의 변경 사항을 재검토하면서 오류를 발견하는 일은 흔합니다. PR은 꼭 문서로 코드를 설명하지 않더라도 PR 자체가 의미를 가지는 코드의 단위입니다. PR 자체가 코드를 문서화하는 것이죠. 즉 변경 점의 최소 단위인 commit 단위의 기록이, feature 단위의 기록이 PR로 남기 때문에 일종의 기록, 혹은 자동화된 documentation의 기능을 수행하는 것입니다.

또한 PR을 만드는 것은 복구 가능한 시점을 만드는 것이기도 해서, 초심자분들에게 큰 도움을 줄 수 있습니다. PR을 사용하지 않고 머지하게 될 경우 복구가 어려운 반면, PR을 사용하면 대부분의 기록이 remote에 남게 되고, 실수한 경우 쉽게 되돌릴 수 있습니다.

모든 변경 사항을 PR로 관리하려면 처음에는 시간이 많이 소요될 수 있고, 특히 처음에는 익숙하지 않아 실수를 할 수도 있습니다. 그러나 PR을 통한 작업 관리에 익숙해진다면, 이로 인한 시간 소모는 점차 줄어들게 될 것이며, 향후에 팀 프로젝트를 진행할 때 큰 도움이 될 것입니다.

팀 프로젝트

팀 프로젝트에서는 PR의 장점이 더욱 두드러집니다. 모든 팀원이 코드 리뷰를 통해 다른 사람이 작성한 코드를 확인하면서 지식을 공유하고 코드의 품질을 개선할 수 있습니다.

더불어 PR은 프로젝트의 투명성을 높여 주고, 작성자의 의도를 쉽게 파악할 수 있게 해 줍니다. 코드의 작성 배경, 목적 그리고 주요 내용을 문서화해 두면, 다른 팀원들의 관련 작업이 쉬워지는 것이죠. 혜택을 받는 대상에는 다른 팀원뿐만 아니라 작성자 본인도 포함됩니다. 왜 이런 코드를 작성했는지 잊어버린 미래의 본인 말이죠.

PR을 통해 문서화하는 일은 수고가 들어가는 일이지만, 그만한 가치가 있는 일입니다. PR을 통해 프로젝트의 참여하는 개개인이 절약하는 시간을 모두 합쳐 본다면 상당히 큰 부분일 것이기 때문이죠.

Pull Request의 상태

• Open : Open 상태의 PR은 아직 검토가 완료되지 않았거나, 추가적인 작업이 필요한 상태를 말합니다. 이 상태에서는 더 많은 커밋을 추가하거나, 토론을 진행하며 수정을 요청할 수 있습니다. 해당 상태의 PR은 아래의 녹색 아이콘으로 표시됩니다.
• Merged : Merged 상태의 PR은 소스 코드의 기본 브랜치로 병합된 상태를 말합니다. Pull Request 화면에서 Merge 버튼을 누르게 되면 해당 상태로 변경되게 됩니다. 이는 해당 PR의 변경 사항이 승인되었고, 코드에 통합되었다는 것을 의미합니다. PR이 병합된 후에는 Closed 상태로 표시되며, 이후 추가적인 변경이나 커밋을 추가할 수 없습니다. Merged 상태의 PR은 아래와 같은 아이콘으로 표시됩니다.
• Closed : Closed 상태의 PR은 거부되었거나, 더 이상 유효하지 않은 PR을 말합니다. 이 PR은 병합되지 않았지만 더 이상 필요하지 않거나 다른 이유로 인해 종료된 상태입니다. UI에서 Closed 버튼을 눌렀을 경우 PR은 Closed 상태가 됩니다. Closed 상태로 전환된 후에도 브랜치가 존재한다면 다시 Open 상태로 되돌릴 수 있습니다. Merged 상태도 Closed 상태로 취급하기 때문에 Closed 탭에는 Merged와 Closed 상태의 모든 PR을 확인할 수 있습니다. 해당 상태의 PR은 아래와 같은 아이콘으로 표시됩니다.

PR의 방법 3가지

• Create a merge commit : 각 브랜치의 변경 사항이 과거의 커밋으로 보존되고, 새로운 커밋이 추가되어 최종 병합하는 방식
  • 장점 : 브랜치의 히스토리를 모두 유지하면서 변경 사항을 병합할 수 있다는 장점이 있어서 프로젝트의 진행 상황을 명확하게 이해하고 추적할 수 있습니다.
  • 단점 : 커밋 히스토리가 복잡해질 수 있어 팀이 커질수록 이 복잡성도 빠르게 증가하게 됩니다.
• Squash and merge : 브랜치에서의 모든 변경 사항을 하나의 커밋으로 압축하여 병합하는 방식
  • 장점 : PR에서 발생한 자잘한 문제들을 숨기고, 그 PR에서 가장 중요하고 필요했던 내용들만 압축하여 담게 됩니다.
  • 단점 : 각 커밋에 대한 개별적인 맥락이나 작업자의 정보 등이 포함되지 않기 때문에 추후 문제 해결이 어려울 수 있습니다. 하지만 GitHub에는 커밋 기록들이 모두 남아있기 때문에 PR을 검색해서 해당 작업의 커밋 히스토리를 확인할 수 있습니다.
• Rebase and merge : 현재 브랜치를 targer 브랜치에 재위치(rebase)시킨 후 병합하는 방식
  • 장점 : 깨끗하고 선형적인 커밋 히스토리를 만들어 준다는 장점이 있어 히스토리를 파악하는 것과 코드의 변화를 이해하기가 쉬워질 수 있습니다.
  • 단점 : 관련된 커밋의 ID들이 모두 바뀌게 되어 혼란을 초래할 수 있다는 단점이 있고 특히 여러 개발자가 동시에 작업을 수행한 경우에는 복잡한 충돌을 일으킬 수 있습니다.

Code Reviews

Code Reviews는 GitHub에서 코드 리뷰를 위한 기능을 제공합니다. Pull Request를 통해 다른 사람들이 작업한 코드를 검토하고 피드백을 주고받을 수 있습니다. 코드 리뷰는 코드의 품질을 향상하고 버그를 예방하는 데에 핵심적인 역할을 합니다. 팀원들은 코드 리뷰를 통해 서로의 코드를 검증하고 개선할 수 있으며, 이를 통해 더 견고하고 효율적인 코드를 개발할 수 있습니다.

Fork

Fork는 Git의 기능이 아니라 git을 호스팅하는 서비스인 GitHub나 GitLab과 같은 서비스에서 제공되는 서비스에서 제공하는 기능입니다. Fork는 기존 repository에서의 모든 변경 사항을 담고 있는 내가 소유한 새로운 repository를 만들어주는 기능입니다. Fork된 repository는 기존 repository와 완전히 분리되어 있으므로 사용자는 자신의 repositroy에서 자유롭게 변경 사항을 반영할 수 있습니다. 작업이 끝난 후에는 Pull Request 기능으로 원본 repository에 기여할 수도 있습니다.

Fork로 Pull Request 생성하는 방법

1. GitHub에서 원하는 프로젝트의 페이지로 이동합니다.
2. 우측 상단에 있는 ‘Fork’ 버튼을 클릭하여 해당 프로젝트를 자신의 계정으로 Fork합니다.
3. Fork된 저장소로 이동하고, 변경 사항을 반영할 브랜치를 생성합니다.
4. 변경 사항을 커밋하고 푸쉬합니다.
5. GitHub 웹 사이트에서 Fork된 저장소로 이동한 후, ‘New Pull Request’ 버튼을 클릭합니다.
6. 변경 사항을 반영할 원본 저장소와 브랜치를 선택합니다.
7. Pull Request를 작성하고 제출합니다.

Pull Request에서 충돌 해결하기

충돌이 발생하게 되면 해결하는 방법은 크게 2가지입니다.

1. Resolve conflict 버튼을 눌러 해결하기

• Accept Current : 현재 브랜치의 내용을 선택
• Accept incoming : 가져오는 브랜치의 내용을 선택
• Accept Both : 두 가지 모두를 선택
• 두 코드를 보고 직접 수정하기
  • <<<<, ====, >>>> 를 삭제 후 직접 코드를 수정

2. 로컬에서 충돌해결하기

• 해당 하는 브랜치로 이동하기 : git checkout [이동하려는 브랜치]
• 코드 머지하기 : git merge main
• 해당 파일을 열어서 <<<< ===== >>>> 로 표시 돼 있는 부분을 직접 수정
• git add와 git commit을 사용하여 해당 파일의 병합이 완료되었음을 Git에 알리기
• git push를 수행

충돌을 최소화하는 방법

• 최신 코드 유지 : 주기적으로 원본 브랜치의 최신 변경 이력을 main 브랜치로 가져오는 것
• 파일을 작게 만들기
• 동료들과 많은 커뮤니케이션 수행하기

Git 명령어 모음

• git init : 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성
• git config user.name ‘usename' : 현재 사용자의 아이디를 'username'으로 설정(커밋할 때 필요한 정보)
• git config user.email 'user@email.com' : 현재 사용자의 이메일 주소를 'user@email.com'로 설정(커밋할 때 필요한 정보)
• git add [파일 이름] : 수정사항이 있는 특정 파일을 staging area에 올리기
• git add [디렉토리명] : 해당 디렉토리 내에서 수정사항이 있는 모든 파일들을 staging area에 올리기
• git add . : working directory 내의 수정사항이 있는 모든 파일들을 staging area에 올리기
• git reset [파일 이름] : staging area에 올렸던 파일 다시 내리기
• git status : Git이 현재 인식하고 있는 프로젝트 관련 내용들 출력(문제 상황이 발생했을 때 현재 상태를 파악하기 위해 활용하면 좋음)
• git commit -m "커밋 메시지" : 현재 staging area에 있는 것들 커밋으로 남기기
• git help [커맨드 이름] : 사용법이 궁금한 Git 커맨드의 공식 메뉴얼 내용 출력
• git push -u origin master : 로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 올릴 때 사용합니다.
• git push : 로컬 레포지토리의 내용을 리모트 레포지토리에 보내기
• git pull : 리모트 레포지토리의 내용을 로컬 레포지토리로 가져오기
• git clone [프로젝트의 GitHub 상 주소] : GitHub에 있는 프로젝트를 내 컴퓨터로 가져오기
• git log : 커밋 히스토리를 출력
• git log --pretty=oneline : --pretty 옵션을 사용하면 커밋 히스토리를 다양한 방식으로 출력할 수 있습니다. --pretty 옵션에 oneline이라는 값을 주면 커밋 하나당 한 줄씩 출력해줍니다. --pretty 옵션에 대해 더 자세히 알고싶으면 **이 링크**를 참고하세요.
• git show [커밋 아이디] : 특정 커밋에서 어떤 변경사항이 있었는지 확인
• git commit --amend : 최신 커밋을 다시 수정해서 새로운 커밋으로 만듦
• git config alias.[별명] [커맨드] : 길이가 긴 커맨드에 별명을 붙여서 이후로 별명으로 해당 커맨드를 실행할 수 있도록 설정
• git diff [커밋 A의 아이디] [커밋 B의 아이디] : 두 커밋 간의 차이 비교
• git reset [옵션] [커밋 아이디] : 옵션에 따라 하는 작업이 달라짐(옵션을 생략하면 --mixed 옵션이 적용됨)(2) staging area도 특정 커밋처럼 리셋(--mixed는 여기까지 수행)그리고 이때 커밋 아이디 대신 HEAD의 위치를 기준으로 한 표기법(예 : HEAD^, HEAD~3)을 사용해도 됨
• (3) working directory도 특정 커밋처럼 리셋(--hard는 여기까지 수행)
• (1) HEAD가 특정 커밋을 가리키도록 이동시킴(--soft는 여기까지 수행)
• git tag [태그 이름] [커밋 아이디] : 특정 커밋에 태그를 붙임
• git branch [새 브랜치 이름]: 새로운 브랜치를 생성
• git checkout -b [새 브랜치 이름]: 새로운 브랜치를 생성하고 그 브랜치로 바로 이동
• git branch -d [기존 브랜치 이름]: 브랜치 삭제
• git checkout [기존 브랜치 이름]: 그 브랜치로 이동
• git merge [기존 브랜치 이름]: 현재 브랜치에 다른 브랜치를 머지
• git merge --abort: 머지를 하다가 conflict가 발생했을 때, 일단은 머지 작업을 취소하고 이전 상태로 돌아감