[GitHub] GitHub 기초

[공부 내용 정리]

Git과 GitHub는 다른 것!

- Git은 버전 관리 시스템

     - Git은 개발자들에게 필요한 협업환경을 조성하기 위한 수단. 빠른 협업 환경을 조성할 수 있고 그 외에도 다음과 같은 사용 이유가 있음.

          - 이전 코드의 히스토리를 볼 수 있어서 이슈트래킹(프로젝트의 이슈를 추적하고 관리)을 할 수 있음.

          - 대부분의 IDE에서 git을 연동할 수 있게 제공

          - GitHub와 연결할 수 있으며 코드리뷰 가능

-> Git을 사용하면 프로젝트의 버전을 과거로 되돌리거나, 특정 내역을 취소할 수 있음. 그렇기 때문에 프로젝트의 여러 모드를 쉽게 전환하고 관리할 수 있음.

 

- GitHub는 Git으로 관리하는 프로젝트를 올려둘 수 있는 사이트

 

+) SourceTree는 Git의 GUI 툴이다!

 

Git의 작동 구조

• push : 원격저장소로 올림
• pull : 로컬저장소로 가져옴
• git pull : 소스 코드 업데이트 O, 업데이트 된 걸 다 받아옴
• git fetch : 소스 코드 업데이트 X, 메타 데이터를 받아옴

GUI

: Graphical User Interface

→ 사용자가 아이콘, 메뉴, 버튼, 창 등의 그래픽 요소를 사용하여 컴퓨터, 스마트폰, 디지털 기기 등과 상호 작용할 수 있도록 하는 시각적 인터페이스

CLI

: Command-Line Interface

→ 글자를 입력하여 컴퓨터에 명령을 내리는 방식. 예를들면 DOS, 명령 프롬프트, Unix 셸

 

용어 정리

• Working Directory : 작업자의 현재 시점, 파일 수정, 저장 등의 작업을 하는 디렉터리. ‘작업 디렉터리’ 라고도 함.
• Repository : 저장소
  • Remote Repository (원격 저장소) : 다른 사람과 공유 가능
  • Local Repository (로컬 저장소) : 내 PC에 저장되는 파일
• Branch : 작업할 때 메인 브랜치에서 뻗어나와 브랜치를 생성하고, 해당 브랜치에서 작업한 후에 작업이 완료되면 메인 브랜치로 Merge하여 개발을 완료함.
  • 사용하는 이유 1 : 만약 기능 개발 중 A, B 기능이 있으면 각각 A, B 를 개발하고 메인 브랜치로 merge를 할 수 있음.
  • 사용하는 이유 2 : 내가 feature 브랜치를 작업 중일 때 다른 사용자가 another feature 브랜치를 작업 할 수 있음.
• Merge : 다른 브랜치의 내용을 현재 브랜치로 가져와 합치는 작업.
• Commit : 현재 변경된 작업을 저장소에 저장하는 작업.
• Checkout (= Switch) : 다른 branch 작업을 불러오는 것.

git push, commit 실습 정리

로컬 위치 보려면 탐색기로 확인하기

commit) 파일 수정 후 → 소스트리 파일 상태에서 업로드하기(+) → 커밋 메시지 쓰기 →커밋

 

git reset, revert 실습 정리

• Git에서 과거로 돌아가는 두 방식
  • reset : 원하는 시점으로 돌아간 뒤 이후 내역들을 지움, 히스토리 안 남음.
    • git reset —hard 커밋해시 : reset을 CLI에서 하기
  • revert : 되돌리기를 원하는 시점의 커밋을 거꾸로 실행함. 우리가 흔히 사용하는 “실행취소”와 같음. 히스토리 남음.
    • git revert 커밋해시 : revert를 CLI에서 하기
• git log : 로그 내용 보는 명령어

커밋해시. 글자 안겹치게만 잘 가져오면 됨.

• 소스트리 충돌 해결

→ <<< HEAD 부터 === 까지는 현재 저장소에 작성되어있는 내용을 보여줌.

→ === 부터 >>> parent 까지는 revert 대상 브랜치에 작성되어 있는 내용을 보여줌.

“내것” → abc

“저장소” → a

“해결된것으로 표시” → 메모장에서 수동으로 고친 누르면 적용

그리고 커밋을 하면 적용! 재밌다..

• revert 충돌 원리

간단명료 설명!! bb

https://velog.io/@chosj1526/git-revert시-Conflict가-발생할-수-있는-상황과-이유

그니까 중간에 revert 하면 바로 이전 실행 기록이 무시됨.

---

Branch 만들기

• 프로젝트를 하나 이상의 모습으로 관리해야 할 때
  • 예) 실배포용(release 브랜치), 테스트서버용(qa 브랜치), 새로운 기능 개발용(feature 브랜치)
• 여러 작업들이 각각 독립되어 진행될 때
  • 예) 신기능 1, 신기능 2, 코드개선, 긴급수정...
  • 각각의 브랜치에서 작업한 뒤 확정된 것을 메인 브랜치에 통합. 주로 develop 혹은 master 브랜치로 통합
•  git checkout main : main branch를 checkout (변경 또는 전환) 하는 명령어

---

서로 다른 브랜치를 합치는 두 방식

• merge : 두 브랜치를 한 커밋에 이어붙임.
  • 브랜치 사용내역을 남길 필요가 있을 때 적합한 방식.
• rebase : 브랜치를 다른 브랜치에 이어붙임.
  • 한 줄로 깔끔히 정리된 내역을 유지하기 원할 때 적합함.
  • 이미 팀원과 공유된 커밋들에 대해서는 사용하지 않는 것이 좋음.

Branch 간 충돌 해결하기

- 파일의 같은 위치에 서로 다른 내용이 입력되어 충돌되었을 경우.

-> 1. merge 충돌 해결하기

conflict-1로 병합을 시도하면 충돌 발생.

   

     - 오류 메시지와 git status 확인

     - 당장 충돌 해결이 어려울 경우 git merge --abort 명령어로 merge 중단

     - 해결 가능 시 (충돌 부분을 수정한 뒤) git add . 하고 git rebase --continue 명렁어로 계속

     - 충돌이 모두 해결될 때까지 반복

 

 

 

---

소스트리에서 작업한 것을 push로 깃허브에 올리면 등록이 됨.

실제 협업에서는 2명 이상의 동의를 얻어야 merge 가능.

댓글도 달 수 있음.

→ 추후에 공부를 더 해야할듯! 깃허브 너무 어렵다……. 근데 확실히 왜 개발자들이 다 깃허브를 쓰는 지 알 것 같다.