노션 이동 완료Git : GitHub // Git(5)

• 얄코님의 git강좌에서 배운 내용을 정리
• github에 관함. 세부내용은 다음과 같음
  
  • github이란?
  • personal access token만들기
  • github 사용 : push / pull
  • 에러케이스 1),2)
  • (로컬)에서 원격의 브랜치 다루기
  • 기타 Github의 유용한 기능들

---

1.GitHub이란?

• git의 원격 저장소
• 협업과정에서, 누군가(A)가 작업을 완료해서 github에 올리면 그 즉시 github은 최신화가 된다(당연)
• 그 후, B가 완료한 작업을 올리기 위해서는 반드시 github상의 최신 커밋을 먼저 받아서 자기 컴퓨터에 있는 프로젝트에 적용부터 하도록 강제가 됨
• 커밋상의 충돌사항이 있다면 그것도 자기컴퓨터에서 먼저 해결하고(병합등을 통해) 나서야 자신이 작업한 커밋을 github에 올릴 수 있음
• 결론적으로, 로컬상에서 github의 최신버전을 적용해보고 문제가 없으면, 그제야 github에 자신의 커밋을 올릴 수 있도록 하기 때문에 마음편하게 원하는 대로 협업이 가능하다.

 

2.Personal access token

• git의 프로젝트를 올릴때 확인용으로 넘겨주는 일종의 비밀번호 토큰
• git hub  로그인 > 우측상단의 프로필 > settings > developer settings > personal access token > generate new token
• note / expiration / scope(토큰의 접근 권한범위) 설정한 뒤(나는 scope를 repo만 체크했음), generate token 생성
  • 이거 scope반드시 설정해줘야 함!!!!!!!. 안해줘서 시간많이 날림 ㅠㅠ
• 하면 토큰키가 나오는데, 이거 따로 메모해둬야 함(다시는 안나옴)
• 이제 토큰키를 저장해야 함
  • window 시작 > Windows 자격 증명 관리자 > windows 자격증명
  • git:https://@github.com이 있으면 자격 정보 생성, 없으면 편집
  • 사용자이름에 , github의 profile이름 입력, 암호에 아까 얻은 token넣을 것

 

3.1 Github 사용 : push하기

1)로컬의 Git저장소에 원격 저장소로의 연결 추가

• 밑의 코드에서 origin은 원격 저장소 이름임. 기본 설정이 origin임

git remote add origin (원격 저장소 주소:https://github.com/tbhumblestar1245/20220201git_practice)

2)기본 브랜치명 변경

• 필수는 아니나, git이 권장하는 것임. 원래는 Master임

git branch -M main

3)로컬 저장소의 커밋 내역들을 원격 저장소(git hub)로 push(업로드)

• 내 로컬에 있는데, 원격에 없는 것을 업로드 하는 것임(처음부터 다가 아니라)
• 밑의 코드는, origin 원격저장소의 main브랜치를 기본 연결 상태(default)로 하고, 거기에 push하겠다는 뜻임
• 이걸 해주는 이유가, 한 프로젝트에서 여러개의 원격저장소를 만들 수 잇음(git remote -v를 입력하면 연결된 원격저장소를 확인 가능)

git push -u origin main

 

3.2 Github 사용 : pull하기

1)로컬의 Git저장소에 원격 저장소로의 연결 추가

• code > downloadzip을 가면 코드들을 다 받을 수 있긴 한데, git파일이 없음. 즉 git의 관리내역이 없음. 따라서 협업과정에서는 이렇게 하지 않음
• 프로젝트를 다운받기 원하는 폴더이동 > 우클릭 > 더많은 옵션 표시 > git bash here > git bash가 이 폴더에서 열림. 그다음 다음을 입력

git clone (원격 저장소 주소)

• 깃의 파일과 깃의 관리내역을 내 컴터로(방금 폴더 위치로) 복사하는 것

 

2)원격 저장소에서 pull

• 그냥 이것만 하면, 연결되어 있는 원격저장소에서 최신까지 파일과 깃내역을 다 가져옴

git pull

 

 

2.1) pull할 것이 있을 때, push하면?

• 즉 내가 github에서 파일들을 받은 이후에동료가 github에 커밋을 했고 나역시도 로컬에서 따로 커밋을 한 상태일때, 내가 github로 push를 하면 어케될까?
  • 앞서 말했듯이 원격에 먼저 적용된 새 버전이 있으므로 적용을 할 수가 없다.
  • pull해서 원격의 버전을 받아온 다음 push가능
  • 근데 단순히 pull하면 , 내가 한작업이 사라짐 >> merge나 rebase하듯이 병합을 해줘야 함

 

• merge방법. no-rebase라고 하니까 = merge임

git pull --no-rebase

 

 

• rebase방법. 원격의 커밋을, 원격과 분기된 지점 다음에 원격의 커밋을 붙이고, 그 위에 내가 한 커밋을 붙임

git pull --rebase

 

• 원격에 누군가 또 push를 해놧어도, 그냥 강제로 내 작업들로 push를 할 수도 있음
• 즉 내 로컬의 git이 최신이 아니여도, 그냥 원격을 밀어버리고 강제로 push를 해서, 원격을 내 local로 맞출 수 있다는 것
• 당연히 내가 pull한것 이후에 만들어진 원격의 커밋들이나 변경점들은 사라짐

git push --force

 

2.2)pull과정에서 충돌이 발생하면?

• 뭐 그냥 별거없음. 원래 차원 합칠떄 나는 충돌을 해결하는 느낌으로 하면 됨
• 헷갈리면 그냥 branch 파트의 충돌 참고
• pull할때는 rebase해서 내려받아도 괜찮음다만 기억할 점은, rebase는 합치는 과정에서 어떤걸 택하느냐에 따라 추가되는 커밋의 개수가 달라질 수 있음

 

4. (로컬)에서 원격의 브랜치 다루기

1)로컬에서, 원격의 브랜치 생성

• 로컬의 브랜치를 생성하듯이, 로컬에서 원격(github)의 브랜치를 생성하고 push할 수 있음
• 다음과 같이 하면 에러가 발생함. 새로 생성된 브랜치를 원격의 어떤 브랜치에 연결할지 명시해줘야 함

#from-local 브랜치 생성 및 이동
git branch from-local
git switch from-local

#push > 에러발생
git push

 

• 아래의 명령어로 원격의 브랜치 명시 및 기본으로 설정
• 이 과정에서, 원격(github)에서 from-local이라는 브랜치가 생성되고, 로컬의 from-local브랜치의 기본 연결 브랜치로 지정이 됨

git push -u origin from-local

 

• 브랜치 목록 살펴보기
• 다음과 같이하면, 로컬의 브랜치뿐 아니라 github 브랜치 목록을 살펴볼 수 잇음

git branch --all

 

 

• 원격의 브랜치 삭제

git push (원격 이름) --delete (원격의 브랜치명)

 

2)원격에서 생성되어 있는 브랜치를 로컬에 받아오기

• 원격의 변경사항 확인

git fetch

 

• 로컬에 같은 이름의 브랜치를 생성하고 연결하고 switch
• -t는 -u와 비슷한 느낌임. '생성된 브랜치와 기본(default)으로 연결된 곳을 from-remote로 하겠다~' 라는 느낌

git switch -t origin/from-remote

 

5. fetch와 pull

1)개요

• fetch : 원격 저장소의 최신 커밋을 로컬로 가져오기만 함
• pull : 원격 저장소의 최신 커밋을 로컬로 가져와 merge 또는 rebase

 

2)fetch > pull

• fetch를 쓰는 이유는, 원격에 올라간 내용을 내 로컬로 들고와서 한번 확인을 해보기 위함임
• 우선 fetch를 활용해 원격의 커밋을 로컬로 들고옴 > git fetch
• 들고온 원격의 커밋은 아직 내 main과 합쳐진 것이 아니기 때문에, 직접 가서 확인을 해봐야함 > git checkout origin/main
• 보고 괜찮으면 로컬 브랜치로 이동해서 pull로 적용

#fetch
git fetch

#origin 브랜치에 가서 확인
git checkout origin/main

#로컬로 이동
git swtich main

#pull
git pull

 

 

3)원격의 새 브랜치 확인 후, 동일한 이름의 브랜치를 로컬에 만들어주기

• git fetch >> 새 브랜치가 있다고 말해줌 > 'git checkout origin/(새브랜치명)' 으로 가서 확인
• 확인해보고 괜찮으면 ,동일한 이름의 브랜치를 생성 : git switch -t origin/(브랜치명)
• main과 합칠거면 merge나 rebase를 사용하면 됨.(이미 한번 받아와서 pull은 사용할 수 없는 듯함)

#원격의 내용을 가져옴
git fetch

#로컬에서, 원격의 새로운 브랜치를 접근하여 내용확인
git checkout origin/(브랜치명)

#로컬에서, 원격의 브랜치와 동일한 이름+커밋(내용)으로 브랜치생성
git switch -t origin/(브랜치명)

 

6. 기타 Github의 유용한 기능들

1) 프로젝트 폴더에 대한 문서 : README.md

• github에 들어갔을 때, 해당 깃헙레포지토리 및 폴더에 대한 설명을 위한 readme.md파일을 만들 수 있음
• 최상위경로에 존재하는 README.MD파일은 최상위 폴더(레포지토리)설명을 위한 문서가 되고, 특정 경로 안의 README.MD파일은 해당 경로를 설명하기 위한 문서가 됨(그 폴더에 들어가면 자동으로 미리보기처럼 나옴)
• README.MD 파일은 마크다운으로 작성됨
• 마크다운 가이드 : https://www.markdownguide.org/cheat-sheet/

 

2) Pull request

• '내가 다른 브랜치에서 코드를 수정했으니, 이 브랜치(코드)를 가져가 검토 후 병합해주세요!'
• 단순히 변경사항을 pull하기전에, 어느정도 리뷰를 거치기 위한 기능
• 누군가의 pull 요청(request) >> 팀원들의 동의를 거친 뒤에야 pull이 되어 브랜치에 적용된다.
• pull request는 반드시 새브랜치에서 코드 수정 > add , commit , push를 해야하며, 이떄 push할때 수정작업을 진행한 branch명을 명시해야 한다.

$ git push origin (수정작업을 진행한 브랜치 이름)

• 참고 : https://dev-youngjun.tistory.com/47
• 깃헙에 pull request 창이 뜨면, 들어가서 pull request를 작성할 수 있다
• 동료들이 그걸보고 comment를 남기거나, request를 종료하거나, pull request를 승인(Merge pull request) 해줄 수 있음

 

3) issue

• github repo에서 issues클릭
• label이나 milestone, asignee 등을 지정한 후 issue를 생성하면 됨
• milestone : 이슈의 주제.(특정 기능에 관해서 라든지..)
• issue가 해결되면 issue를 close!

 

4) 오픈소스에 참여하기(Fork)

• Fork : 레포지토리 전체를 복사하는 것
  • 복사해올 레포지토리에가서, fork를 누르면 내 레포로 내용들이 복사되어서 들고와짐
  • 그러면 이제 권한이 나한테 있으니까 마음대로 작업을 진행할 수 있음
  • 혹은 그냥 bash를 이용해 clone >> vs코드로 작업 뭐 이런식으로 진행할 수도 있음
• 암튼 작업 완료 후 push > pull request가 생김 >> 그러면 자동으로 원래 주인한테 pull request를 보낼 수 있음
  • 내가 이렇게 작업했는데, 이렇게 수정하는게 어떠냐~ 하고 제안을 보내는 것
  • 그럼 오픈소스의 주인관점에서 풀 리퀘스트를 코멘트/반려/수락을 하는 것

 

5) Github 블로그 만들기 : Github pages 사용하기!

• github페이지마다 무료로 정적 웹 호스팅을 제공해줌
• 생성방법
  • 레포지토리명을 꼭 '내아이디.github.io' 로 해줘야 함!!
  • 로컬로 클론
  • 클론이 진행된 폴더에 index.html 작성 후 push (이렇게 작성하면 바로 호스팅이 된다. js/css등을 적용시켜주면 됨)
  • https://tbhumblestar.github.io/ 에서 사이트 확인

 

6) SSH로 접속하기

• SSH
  • 공개키 암호화 방식
  • username과 토큰을 사용할 필요가 없어짐
  • 컴퓨터 자체에 SSH키가 저장되는 구조. Git뿐만 아니라, SSH키를 사용하는 기타 사이트나 서비스에서 사용가능
• SSH키 생성
  • 먼저 컴퓨터에 SSH키가 있는지 확인하고, 없을 경우에 만들어줘야 함 ( 참고(git 공식 홈페이지) : https://docs.github.com/en/authentication/connecting-to-github-with-ssh) 
  • SSH키가 존재하는지 확인할 때, SSH키를 만든적이 없으면 directory자체가 존재 하지 않는다고 나올 수 있음. 그렇게 나오면 그냥 무시하고 바로 키생성하면 됨
  • 키생성 할때 뭐 진짜 할건지 물어보는데 yes하면되고, 그다음 비번 입력하라는데 하기 싫으면 그냥 엔터두번갈겨도 됨ㅇㅇ
  • 키가 잘 생성되었을 경우, 해당 경로(~/.ssh)로 가서 목록확인(ls)를 해보면 private key와 public key가 생성됨. public key는 뒤에 .pub가 붙은 것임
  • pub키를 열람 & 복사

#SSH키 존재여부 확인
cd ~/.ssh
ls

#SSH키 생성. 이때 원하는 경우 passphrase(비밀번호) 입력
ssh-keygen -t ed25519 -C "(이메일 주소)"

#키가 존재하는 위치로 이동
cd ~/.ssh
#공개키 열람&복사
cat ~/.ssh/id_ed25519.pub

 

• SSH키 등록
  • 쉬움. github > settings > SSH and GPG keys > SSH키 등록 > title은 내맘대로(설명) , Key에 방금 복사한 public key를 적어주면 됨

 

• SSH키로 접속하기
  • 먼저 테스트를 위해 로컬과 github의 연결을 끊어줌
  • 그리고 그냥 ssh키주소를 사용해서 origin을 등록하면 끝임
  • 참고로, 연결을 끊었다 다시 이어주었으므로 pull하거나 push하기 위해선 로컬과 연결할 remote(origin)의 브랜치를 설정해줘야 함!

#로컬과 연결된 github확인
git remote -v

#로컬과 github의 연결을 끊음
git remote remove origin

#ssh키를 사용해 로컬과 github의 연결
git remote add origin (ssh키 주소)
#예시
git remote add origin git@github.com:tbhumblestar/20220201git_practice.git

#로컬과 연결된 github확인
git remote -v

#pull
git remote origin main

#push : origin의 main과 연결하는 것을 기본설정으로 하고, push도 실행
git push -u origin main

 

 

• SSH키의 원리
  • public_key와 private_key는 어떤 알고리즘으로 연결되어 있음. (즉 대조를 통해 둘이 맞는지를 확인할 수 있다는 뜻)
  • 방금처럼 위에서 공개키를 서비스에 전달해 둔 후, 인증이 필요할 경우 컴퓨터는 private_key를 서비스에 제공
  • 해당 서비스는 기존에 받아서 가지고 잇는 public_key를 기존에 받은 private_key와 비교하여 둘이 알고리즘적으로 맞을 경우 인증을 승인해 준다.

 

7) GPG로 커밋에 사인하기

• gpg키?
  
  • 커밋들을 보면 다음 사진과 같이 verified가 있는 커밋이 있음
  • 깃에서 신뢰할 수 있다는 뜻인데, verified를 얻는 방법은 두가지임. GPG키를 활용해 커밋하거나 or github에서 직접수정하여 커밋하거나
  • github에서 직접 수정하면 그냥 git이 따로 검사할 필요 없이 바로 확인되니까 verified를 주는 듯

 

• gpg키 생성
  • 우선 gpg툴을 설치해야 함.
    • 사이트 : https://www.gnupg.org/download/ 사이트는 github공식페이지에서 찾다보니까 나온 곳임
    • 사이트에서 windows > gpg4win을 받으면 된다!
    • bash에서 gpg --version을 입력했을 때 뭐라뭐라 뜨면 잘된 것임
  • gpg키가 있는지 확인(https://docs.github.com/en/authentication/managing-commit-signature-verification/checking-for-existing-gpg-keys)
  • gpg키가 없다면 다음 사이트를 따라 만들면 됨(https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key). 모르겠으면 강좌 참고

 

• GPG키 등록 
  • 바로 위에서 생성된 GPG키를 복사해서,  github > settings > SSH and GPG keys > GPG키 등록에서 등록하면 됨
  • 이제 로컬에 설치된 깃(깃헙말고!!)에도 말해줘야 함
  • 다음의 코드를 입력하고 마지막에, gpg키를 생성하면서 얻게된 sec가 있는데, 그걸 입력해주면 됨

git config --global user.signingkey (얻게된 sec)

 

 

• GPG키 사용
  • 커밋할 때 다음과 같이 '-S'를 추가해주면 됨
  • 그러면 비밀번호를 입력하라고 나옴. 입력하면 됨
  • 그렇게 commit 후에 push를 해보면 verified가 되어있음
  • 태그에도 적용해서 verified를 받을 수 있음. 태그는 대문자가 아니라 소문자 '-s'를 입력해 줘야 함

#커밋에 GPG키 사용
git commit -S -am "gpg_test"

#태그에도 가능!
git tag -s (태그명) (커밋 해시) -m (메시지)

 

verified가 되어있다. gpg키를 활용해서 등록했기 때문

 

8) Git action

• 마치 git hooks처럼, github에서 여러가지 action을 한번에 묶어서 자동화 하는 것을 의미함
• 예를 들어, github에서 제공하는 정적 홈페이지에 우리가 새로운 내용을 push할 경우 단순히 github에 커밋되는 게 아니라 커밋된 내용을 바탕으로 홈페이지가 새롭게 그려지는 등, 여러가지 작업이 자동적으로 한번에 묶여서 수행됨. 이러한 기능을 git action이라고 함
• 그 외에도, pull request등을 수행할 때 자동적으로 전체적인 테스트가 되게 한다든지 다양한 기능을 한데 묶어서 쓸 수 있음... 마치 데코레이터 같은 기능
• 다만.. 아직은 언뜻봐도 굉장히 복잡해보임.. 일단은 이런게 있다.. 정도로만 알아두고 나중에 이런저런 지식이 쌓였을 때 사용할 수 있도록 하자

 

9) Octotree

• github레포지토리를 마치 탐색기처럼 훨씬 더 편하게 사용이 가능함
• 크롬 익스텐션임 (https://chrome.google.com/webstore/detail/octotree-github-code-tree/bkhaagjahfmjljalopjnoealnfndnagc)

 

10) Gihub CLI

• 깃헙전용 CLI툴
• 굉장히 직관적이고 쉽게 되어 있어서, 배우기도 쉽고 익숙해지면 매우 편안한다!(by선생님)
• 공식사이트 : (https://cli.github.com/)