본문 바로가기
Development/DevOps

[Git]Git 입문자를 위한 Github 사용법

by 다봄이 2020. 8. 7.

최근에 좋은 기회가 생겨 교육생의 신분을 획득하였다.

 

그런데 생각보다 깃을 처음 사용하시는 분들이 많아서!! 불과 몇 달 전의 내 모습을 보는 것 같아서!! 완전 입문자의 마음가짐으로 처음부터 깃 사용 방법을 정리해볼까 한다.


작업을 시작할 때

원격 저장소(github, gitlab)에서 진행할 것

  1. 새 레포지토리를 생성한다.
  • 적당한 레포 이름을 적고, 레포를 공개할 것인지 개인 레포로 둘 것인지 체크한다.
  • 참고로, 나는 개인적으로 처음 레포 생성시에는 private으로 생성하고, 개발 마무리 단계에서 저장소를 public으로 돌리는 것을 선호한다.
  1. 경로 확인

로컬 저장소에서 진행할 것

git init 
git remote add 원격저장소이름 원격저장소경로
  1. git init
  • 원하는 폴더에서 init 명령어를 사용한다.
  1. git remote add 원격저장소이름 원격저장소경로

이 때 원격 저장소 경로를 잘못 연결하거나, 이름을 잘못 연결한 경우도 있을 수 있다. 다음과 같은 방법으로 잘못 연결한 원격 저장소를 삭제할 수 있다.

git remote -v //해당 로컬과 연결된 원격 저장소 이름과 주소 확인 
git remote remove origin //origin이라는 이름으로 연결된 원격 저장소 삭제

Clone

로컬에서 작업을 시작한 것을 원격 저장소에 올리는 것 말고, 원격 저장소에 이미 있는 파일을 가져와서 작업을 진행하는 경우도 있다. 이 때는 원격 저장소의 파일을 받아와야 하는데, 이것을 클론(clone)이라 한다.

git clone 원격저장소경로
  • 원격 저장소의 파일을 저장할 적당한 경로를 지정하고 git clone을 하면 되는데, 나는 주로 vscode의 terminal을 이용하거나 git bash를 이용해서 git 명령어를 수행한다.
  • 이 때는 init같은 과정 없이 원하는 폴더에서 바로 clone 명령을 수행하면 된다.


작업을 진행하는 도중

1.변경사항을 add하고 commit하기.

로컬에서 작업하던 것을 원격 저장소에 올리고 싶을 때는 add 후 commit을 해야 한다.

git add fileName 
git commit -m "Commit message"
  • 이 때 주의할 사항이 이 커밋이다. 깃 입문자들의 경우 커밋이 단순히 '메시지를 쓰는 것'이라고 생각하는 경우가 있다. 그러나 위 그림을 보는 것처럼, 커밋은 변경사항을 확정하고 원격저장소에 올리기 위한 작업정도라고 생각하면 될 것 같다. 메시지는 그 커밋을 설명하기 위한 기능이다.
    • 커밋을 하지 않을 경우에는 확정된 변경사항이 아무것도 없기 때문에 원격 저장소에도 변경사항을 푸시할 수 없다.
    • 변경사항이 없을 경우에는 Everything-up-to-date 라는 명령어를 볼 수 있다.

2.확정된 변경사항(커밋한 파일)을 원격 저장소에 올리기

git push 원격저장소이름 브랜치이름

이제 커밋이 끝났으면 원격 저장소에 올리기 위해git push origin master와 같은 명령어를 실행하여 푸시한다.


 

Gitflow

이제 실무에서 많이 사용하는 개발 프로세스를 따를 수 있다.

사무실에서 작업하던 파일을 퇴근 전에 push한다.(git add - git commit - git push) 

수정사항이 생겨서 집에서 해당 repo를 clone해서 수정한 후 push한다.(git clone 저장소경로 - git push) 

다음날 출근하면 가장 먼저 git pull 하여 집에서 수정한 변경사항을 받아온다.(git pull)
  • 원격 저장소와 로컬 저장소의 상태가 다를 때는 반드시 git pull을 진행해야 한다.
    • git pull 원격저장소이름 변경된브랜치이름
    • ex. git pull origin master

예를 들어 깃허브에서 직접 리드미를 수정할 경우에도 원격 저장소와 로컬 저장소에 차이가 생기므로 원격 저장소의 변경사항을 로컬 저장소로 받아오는(땡겨오는) pull작업을 하는 것이다.

 

그러나 Git 초보자들의 경우는 이 싸이클을 잘 모르기 때문에 수정사항이 생겼을 때 새 폴더를 만들어서 작업하고 이를 푸시하는 상황이 종종 발생한다. 그러면 다음날 수정한 파일을 pull 해서 받아오려는데 안 받아져서 당황한다. 두 프로젝트는 완전히 다른 프로젝트이기 때문에 발생하는 현상이다.

 

이럴 경우 원래 파일이 있는 프로젝트와 수정하려고 새로 만든 프로젝트가 서로 같은 곳을 바라보고 있지 않는다고 표현한다. 즉, 원래 프로젝트와 새로 생성한 프로젝트는 완전히 다른 프로젝트인 것이다. 그 때문에 history 또한 완전히 다르다.

 

이처럼 history가 다른 프로젝트 파일을 받아오려면 git push origin master --allow-unrelated-histories하면 된다.

git pull origin 브랜치이름 --allow-unrelated-histories

파일 지우기

  • 잘못 커밋한 로컬 파일 지우기
        git rm filename
  • 원격 저장소에 잘못 올린 파일 지우기
        git rm --cached filename
  • 원격 저장소에 잘못 올린 폴더 지우기
        git rm --cached dirName -r
    • 폴더를 지울 경우에는 파일 여러개를 지우는 것이기 때문에 -r태그(recursive였던 것 같다)를 붙여줘야 한다.

파일이나 폴더를 지운 경우 변경사항이 생긴 것이기 때문에 꼭 커밋을 해야 반영된다.

ex. 원격 저장소에 잘못 올라간 test.py 파일 지우기

git rm --cached test.py 
git commit -m "Fixed file" git push origin master

 


 

브랜치 생성

슬슬 작업을 진행하다보면 프로젝트 파일을 보호하기 위해 , 혹은 협업을 진행하기 위해 브랜치를 분리해야 할 필요성이 생긴다.

git checkout -b 생성할 브런치 이름
  • 한창 작업을 하다가 마스터 브런치로 돌아가고 싶다.
          git chekout master
  • 브랜치를 생성했는데 이름이 틀렸다!! 브랜치 생성 규칙이 바뀌어서 브랜치 이름을 수정해야 한다!?
          git branch -m old_name new_name

마크다운과 리드미

하나의 레포에는 그 프로젝트를 설명하는 리드미가 있기 마련이다.

 

리드미 파일은 다른 파일들이랑 다르게 해당 파일을 클릭하지 않아도 자동으로 보여지는 파일이다. 따라서 리드미에는 해당 프로젝트 설명, maintainer, 오픈소스 설치 방법 등을 포함하곤 한다.

  • 이 리드미 파일은 항상README.md라는 이름으로 생성한다.
  • 리드미의 확장자인 md는 마크다운으로, 마크다운 사용법은 여기를 클릭하면 잘 정리되어 있다.
  • 참고로 README.md를 제외하고 test.md 등 다른 이름을 가진 마크다운 파일은 리드미처럼 자동으로 보여지지 않고, 해당 파일을 클릭해야 볼 수 있다.

 

이정도면 아마 크게 무리없이 git을 사용할 수 있지 않을까 싶다..

 

이것 외에도 커밋 메시지 잘 쓰는 방법, 리드미 예쁘게 쓰는 방법, 이슈 규칙, 브랜치 이름 짓는 규칙 등 여러가지가 남아있지만 이것은 최적화(?)와 같은 기능이므로 여기서는 논외로 한다.

 

+) 커밋 메시지 잘 쓰는 방법

깃(git) 커밋 가이드

좋은 git 커밋 메시지를 작성하기 위한 7가지 규칙

 

+)Git 간편 안내서


이 포스팅을 git린이인 나의 동기(?) 그대들에게 바칩니다.

'Development > DevOps' 카테고리의 다른 글

[Git]그래서 Git이 뭔데?! Git 이론 정리  (2) 2020.10.08

댓글