DeJa
Techvu
DeJa
전체 방문자
48,644
오늘
4
어제
65
  • Techvu (60)
    • DesignPatterns (3)
      • 생성 (0)
      • 구조 (1)
      • 행동 (2)
    • Refactoring (0)
    • DataStructures (0)
    • Algorithms (24)
      • 기본 지식 (12)
      • 문제 풀이 (12)
    • OOP (0)
    • TDD (2)
    • DDD (0)
    • Programming Languages (9)
      • Java (9)
      • Kotlin (0)
    • Spring (1)
    • JPA (7)
    • Web (1)
      • 기본 지식 (1)
      • 실무 경험 (0)
    • CS (12)
      • Network (1)
      • OS (8)
      • DataBase (3)
      • Server (0)
    • Git (1)
    • Conferences (0)

블로그 메뉴

  • 홈
  • 태그
  • 미디어로그
  • 위치로그
  • 방명록

공지사항

  • Study
  • GitHub
  • Medium Blog

인기 글

  • 자바 버전별 역사 및 특징
    2022.01.12
    자바 버전별 역사 및 특징
  • 깃허브 사용 방법
    2021.12.15
    깃허브 사용 방법
  • 스키마(Schema)
    2022.01.08
    스키마(Schema)
  • 동시성 이슈(Concurrency Issue)
    2022.03.20
    동시성 이슈(Concurrency Issue)
  • 재귀 함수(Recursion Function)
    2021.12.08
    재귀 함수(Recursion Function)

태그

  • Spring
  • CS
  • OS
  • DATABASE
  • 디자인패턴
  • java
  • 알고리즘
  • JPA
  • TDD
  • web
  • network

최근 댓글

  • 글 잘읽고 가요.
    아이폰
  • 컴파일러자체에서 꼬리재귀를 지원하지 않으니 static으로⋯
    aaa
  • 압도적 감사
    ㅇㅇㅇ

최근 글

  • Write a test code right now
    2022.03.24
    Write a test code right now
  • 동시성 이슈(Concurrency Issue)
    2022.03.20
    동시성 이슈(Concurrency Issue)
  • POJO, JavaBean, Entity, VO, DTO
    2022.02.08
    POJO, JavaBean, Entity, VO, DTO
  • TDD with Agile
    2022.02.05
    TDD with Agile
  • Java Stream 기초
    2022.01.23
    Java Stream 기초

티스토리

hELLO · Designed By 정상우.
DeJa

Techvu

깃허브 사용 방법
Git

깃허브 사용 방법

2021. 12. 15. 02:33
728x90

깃허브 사용 방법(GitHub Tutorials)

대부분의 개발자들은 원격 저장소인 GitHub 를 한 번쯤은 들어봤을 것이다. GitHub 를 사용하면 프로젝트에 대한 형상관리가 가능하며, 개인 포트폴리오를 올리고 관리할 수 있으며, GitHub 를 통한 오픈소스 프로젝트에도 기여할 수 있다.

GitHub 의 가장 큰 특징은, 오픈 소스 공개 프로젝트에 무료로 Git 저장소를 호스팅한다는 점이다.

이 글(깃허브 사용 방법(GitHub Tutorials))을 검색하여 보는 대부분의 독자님들은 개발자를 꿈꾸는 학생이거나, 주니어 개발자일 것이다. 본인이 개발에 관심이 있고, 취업/이직을 잘 하고싶다면 가장 먼저 해야할 것은 깃허브 계정을 생성하는 것이다. 개발자를 직업으로 삼고자하면 깃허브는 거의 필수라고 해도 과언이 아니며, 잘 정리된 깃허브는 취직에 유리하다.

GitHub 를 가지고 어떻게 자신의 코드를 올리며 관리하는지, 어떤 프로세스로 동작하는지에 대해서 배워보자.

해당 포스팅은, 제 이전 블로그에서 작성한 내용을 개선하여 작성하였습니다.

필자의 깃허브 구경하기

깃허브 프로세스

  • Working Directory : USER
    • 내가 작업하려는 PC 내의 디렉터리
  • Staging Area : INDEX
    • git commit 하기 전에 저장되는 git 의 공간
    • 커밋 예정인 파일, 디렉터리들이 모여있는 공간
  • Local Repository : HEAD
    • 내 PC 에 파일이 저장되는 개인용 저장소
  • Remote Repository : GITHUB
    • 깃허브(원격 저장소)

IDNEX

USER 는 Working Directory 이며, .git 이라는 폴더가 들어있는 상위 폴더를 의미한다.

GitHub Directory > .git, README.md, and so on

이런식으로 GitHub 디렉터리 안에 .git, README.md 등 여러 파일들이 존재하는데, 여기서 GitHub 디렉터리를 Working Directory 라고 부른다. 그리고 git add 명령어에 의해 Staging Area 로 간 파일들은 .git 디렉터리 내의 INDEX 파일과 함께 .git/objects 디렉터리 안에 파일로 관리된다.

  • 인덱스는 다음 항목을 포함한다.
    • 각 파일과 디렉토리의 정렬된 path name 들
    • 각 파일과 디렉토리의 permission
    • blob 객체의 SHA-1 값
    • git ls-files 명령을 사용하여 인덱스의 내용을 볼 수 있다.

git ls-files 명령으로 내용을 보면 다음과 같은 구조로 되어있는 것을 볼 수 있다.

$ git ls-files --stage
100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0    .gitignore
100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0    .mailmap
100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0    COPYING
100644 a37b2152bd26be2c2289e1f57a292534a51a93c7 0    Documentation/.gitignore
100644 fbefe9a45b00a54b58d94d06eca48b03d40a50e0 0    Documentation/Makefile
...
100644 2511aef8d89ab52be5ec6a5e46236b4b6bcd07ea 0    xdiff/xtypes.h
100644 2ade97b2574a9f77e7ae4002a4e07a6a38e46d07 0    xdiff/xutils.c
100644 d5de8292e05e7c36c4b68857c1cf9855e3d2f70a 0    xdiff/xutils.h

만약에 File.txt 안에 ABC 라는 문자를 작성하고 git add 를 했다면, 'ABC' 라는 문자를 SHA-1 이라는 해시 알고리즘으로 해시코드(40자리)를 만들고 그 중에 처음 2자리로는 해당 문자로 .git/object 안에 디렉토리를 만들고 나머지 38자리로는 해당 문자로 이름을 갖는 파일을 만든다.

여기서 예로든 'ABC' 라는 문자는 누가, 어떤 컴퓨터에서 만들든 같은 해시코드(40자리)를 갖는다. 따라서, 누가 만들든 파일의 이름이 달라도 내용이 같으면 해시코드(인덱스 값)가 같기 때문에, 여러 파일을 만들어도 같은 내용일 경우 .git/index파일이 하나로 관리된다.

HEAD

commit도 .git/objects 안에 디렉토리안에 일반적인 파일과 똑같이 관리된다. commit 으로 생성된 파일에는 중요한 정보 2가지가 있는데(2가지만 있다는 것은 아니다.) 다음과 같다.

  • parent : 해당 commit 바로 이전의 상위 commit id
  • tree : commit 을 통해 관리된 파일들의 이름과 내용에 대한 구조

따라서, tree를 통해 파일, 디렉터리 구조로 나타낼 수 있으며, 그 안의 정보도 볼 수 있다.

git branch <branch> 명령을 실행할 때 Git 은 어떻게 마지막 커밋의 SHA-1 값을 아는 걸까? 바로 .git 디렉토리에 HEAD라는 파일을 사용하여 관리하기 때문이다.

이제, 실제로 어떻게 사용하는지 배워보자.

Git 설치하기

Git 설치하기 해당 링크를 통해서 깃을 설치하자.

설치가 완료되면 커맨드 창을 열어 git --version을 입력하여 잘 나오는지 확인해야 한다.

만약에 깃(git)을 설치 했음에도 제대로 작동하지 않는다면 내컴퓨터 > 속성 > 고급 > 환경변수로 들어가서 맨위에 있는 환경변수 path 에서 c:\windows\system32 경로로 수정해주면 작동할 것이다.

깃허브 계정 생성하기

깃을 설치 후 다음으로 해야할 것은, 깃허브(GitHub 계정을 먼저 생성하는 것이다. 링크를 통해 깃허브 계정을 생성하자.

계정을 생성하고 나서 Repositories 라는 탭을 클릭해서 들어간다. 우측 상단에 있는 자신의 프로필을 클릭하고 Your Repositories 를 클릭하여 들어 갈 수도 있다.

여기서 우측 상단에 초록색 버튼의 New 를 클릭하면 아래와 같은 화면이 나온다.

Repository name 과 Description 을 입력후, 누구나 볼 수 있는 public 으로 생성할 것인지, 자신과 자신이 설정한 사람만 볼 수 있는 private 으로 생성할 것인지 선택한다. 여기서는 public으로 선택하고 진행할 것이다.

아래에 Initialize this repository with a README 라는 문구가 적혀있는데 README.md 파일을 생성할 것인지를 물어보는 것이다. README.md 를 생성하지 않더라도 나중에 생성할 수 있다. 여기서 README.md 를 생성 하냐 안하냐에 따라 초기 작업방식이 달라진다.

README를 생성하지 않는 경우

위에서 create repository 를 클릭하면 아래와 같은 화면이 나온다.

친절하게도 ..or create a new repository on the command line 아래에 어떻게 Working Directory 에 git 저장소를 만들고 어떻게 원격 저장소로 푸시하는지에 대해서 자세하게 나와있다.

Working Directory 생성하기

Working Directory 를 생성합니다. 바탕화면에 dev 디렉터리를 만들고 진행할 것이다.

아무것도 없는것을 볼 수 있다. 이제 커맨드 창을 열어서 해당 Working Directory의 주소로 이동한다.

cd WorkingDirectory 주소

Working Directory로 이동 후에 가장 먼저 깃허브 계정을 연동해야 한다.

git config

git config --global user.name "닉네임"
git config --global user.email "이메일"

위 두 개의 명령어를 통해서 닉네임과 이메일을 등록해준다.

git init

이제 git init 명령을 통해서 깃 저장소를 생성해 준다.

자신의 Working Directory에 git 저장소를 생성한 것이다.

이제, 자신의 Working Directory에 들어있는 모든 파일들을 GitHub의 remote repository 로 commit and push 할 수 있다.
위에서 생성하지 않은 README.md 파일을 생성해서 commit and push 해보자. README.md 작성툴은 Notepad, 메모장, ATOM, VSCode 등 어떤 것이든 상관 없다.

.md 파일은 markdown(마크다운) 형식으로 작성된 파일을 의미한다.

README.md 파일은 자신의 repository에 대한 간단한 설명 또는 소개를 적는 파일이라고 생각하면 된다.

잘 작성된 README.md 파일은 다음과 같다.

git add

위에서 생성한 README.md 파일을 git add 명령어를 통해 Staging Area 로 보내자.

  • git add * : 새로 생성한 모든 파일을 Staging Area 로 보냄.
  • git add 파일명 : 해당 파일명을 Staging Area 로 보냄.

git commit -m “message”

git commit -m "message" 명령어를 통해 README.md 파일에 대한 메시지를 입력하고 Local Repository로 보내자.

나중에 현업 개발자로 실무에 투입되어 깃랩(GitLab) 또는 깃허브(GitHub)를 사용하게 되는 경우 커밋 메시지를 자세하게(누가봐도 어떤 파일에 대한 커밋인지 알 수 있도록) 적는 것이 중요하다. 귀찮더라도 커밋 메시지를 잘 적는 습관을 들이는 것이 좋다.

git remote add origin “remote repository url”

git remote add origin "remote repository url" 명령어는 첫 커밋을 할 때만 사용하는 명령어이며 이후에는 사용하지 않아도 된다.

git push -u origin master

git push -u origin master 명령어는 첫 커밋을 할때만 사용하는 명령어이며 이후에는 git push 명령어만 사용하면 된다.

이제 자신이 커밋한 내용이 제대로 들어갔는지 깃허브에서 확인해 보자.

파일이 잘 커밋이 되었지만, contain binary data 때문에 화면에 표시할 수 없다고 나옵니다. 이런경우 해당 파일을 클릭하여 쓰레기통 아이콘을 누르면 파일을 삭제할 수 있다.

삭제하고나면 아래 화면과 같이 README.md 파일을 생성할 수 있는 버튼이 하나 생긴다. 해당 버튼을 클릭하여 파일을 생성할 수 도 있다.

README를 생성하는 경우

Initialize this repository with a README 를 클릭하여 README.md 를 생성하는 경우는 README 를 생성하지 않는경우에서의 2번(git config) 3번(git init)과정이 필요 없다.

git clone

가장 먼저 해야할 일은 git clone 으로 원격 저장소에 있는 모든 파일들을 자신의 Working Directory 로 가져오는 것이다. git clone은 git init 의 효과 까지 있다.

git clone "remote repository url"

git add, git commit, git push

Working Directory 에 새로 생성한 파일들을 git add, git commit, git push 를 통해서 원격 저장소로 커밋 할 수 있다.

git add *
git commit -m "My First Commit"
git push

원격 저장소에서 팀원이 merge 한 파일가져오기

원격 저장소를 혼자 사용하거나 혹은 팀원이랑 같이 사용하는 경우, 내가 Working Directory 에서 작업한 내용이랑 원격 저장소에 저장되어 있는 내용을 동기화 시켜줘야 한다. 만약 팀원이랑 같은 파일을 작업하는데, 나 혼자 동기화를 시키지 않고 add, commit, push 를 수행하면 충돌(conflict)이 발생할 수 있다. 따라서 원격 저장소(깃허브)에서 새로 업데이트된 파일을 Working Directory 로 받아오는 과정은 다음 명령어를 통해서 할 수 있다.

git pull

만약에, 충돌이 난다고하면 충돌을 해결해줘야 할 것이다.

References

  • Git User Manual
  • https://johngrib.github.io/wiki/git-index/
  • https://jeong-pro.tistory.com/104
728x90
저작자표시 비영리 변경금지
  • 카카오스토리
  • 트위터
  • 페이스북
    DeJa
    DeJa
    Tech Blog
    댓글쓰기

    티스토리툴바