Git 이란 ?, git 사용법 + 협업에서의 객체지향의 중요성 (Git과 연결시켜서)

오늘 Git에 대해 조금 공부하게 되었다.

git에 대한 간단 설명

• 일단 git은 형상관리도구(Configuration Management Tool)의 일종으로 버전 관리를 도와주는 시스템이다.

  --> github는 git을 위한 웹호스팅 서비스이다.

• 이런 git은 분산형 관리 시스템을 가지고 있는데, GitHub저장소 ( 메인저장소 ) 뿐만 아니라 여러대의 개발 PC가 로컬 저장소로 소스파일을 저장할 수 있다.

  • 여기서 git의 장점이 나오는데, 협업에 있어서 각각의 개발자가 GitHub저장소 ( 메인저장소 )에 올릴 시점에 Branch개념과 Merge개념을 사용하여 혼란을 최소화하였다.

    1. Branch 개념을 사용하여 ( 여러 개의 나뭇가지처럼 ) 각각의 개발자가 협동 작업을 할 때 현재 상태를 복사하여 각자의 Branch에서 작업을 한 후, 완전하다 싶은 상황에서 Merge를 통해 master Branch에 통합시킨다.

    2. merge 개념을 사용하여 Branch를 최대한 직관적인 방식으로 통합시킨다. 다른 개발자의 Branch를 가져와 자신의 Branch와 통합시킬 때, 다른 개발자의 Branch와 벌어질 혼선을 최소화하고, 개발자가 직관적으로 소스의 변경사항을 파악할 수 있도록 돕는다.

    3. 각 Branch에 "히스토리" 및 "버전"의 개념을 도입하여 Merge를 통해 Branch에 변경이 있을 때마다 Repository(저장소)에 각 분기점을 자동으로 기록하게 된다. 이를 통해 개발 이력을 시각적으로 파악할 수 있고, 현재 개발방향에 문제가 있을 경우 빠르게 소스코드를 과거의 특정 시점으로 되돌릴 수 있다.

  실전에서는 어떤 식으로 사용해야할까?

  협업 과정에서 master Branch( 메인 )는 기준이 되는 Branch이므로 다른 개발자들의 Branch와의 충돌을 줄이기 위해 내 맘대로 마구잡이로 merge할 수는 없다.

  하지만 그렇다고 2주든 1개월이든 너무 오랜기간 merge 없이 내 branch안에서만 개발해서는 안된다.

  그 이유는 이렇게 해버리면 나중에 master Branch에 몰아서 merge하는 순간에 다른 개발자들과의 혼선문제로 인해 수정해야할 conflict가 너무 많아지기 때문이다.

  따라서 master Branch의 변화를 지속적으로 내 Branch로 가져와서 충돌나는 부분을 매번 제거하면서 내 Branch를 개발해야지 추후에 master Branch로 통합할 때 conflict를 줄일 수 있다.
  

---

협업에서의 객체지향의 중요성 (Git과 연결시켜서)

객체지향을 기본으로 한 소스코드는 다른 개발자의 Branch와 merge할 때, conflict를 최소한으로 줄어준다.

이는 결과적으로 작업량을 줄어주고 버그의 발생을 막는 것에 기여하기 때문에 매우 중요하다.
( 이는 git 뿐만 아니라 대부분의 협동 개발에서 그렇다. )

따라서 프로젝트에서 협업을 진행할 경우에 객체지향을 기본으로
대부분의 기능을 모듈화 시키는 것을 추천한다.

---

관련 용어들

• Repository (저장소) : 히스토리, 태그, 소스의 가지치기( Merge로 인한 Conflict 수정 ) 혹은 branch에 따라 버전을 저장한다. Repository를 통해 작업자가 변경한 모든 히스토리를 확인 할 수 있다.

• Staging Area : local repo에 commit하기 전에 준비하는 위치.

• Head : 현재 작업중인 Branch

• Commit : 현재 변경된 작업 상태를 점검을 마치면 확정하고 저장소에 저장하는 작업.

• Branch : 가지 또는 분기점을 의미하며, 작업을 할때에 현재 상태를 복사하여 Branch에서 작업을 한 후에 완전하다 싶을때 Merge를 하여 작업을 한다.

• Merge : 다른 Branch의 내용을 현재 Branch로 가져와 합치는 작업을 의미한다.

---

git 사용하기 -> git terminal 코드 사용

초기설정과 관련한 부분

1. 로그인

   git config --global user.name "유저이름"
    git config --global user.email "유저 이메일"

git을 다루는 부분

git의 흐름은 위의 표를 보고 참고 할 것

파일 준비

• 파일 생성

  git init

• 스테이징( staging )하기

  • staging에 대해서

    • 폴더 또는 파일을 다루기 위한 준비하는 단계로 git에 담는 과정이다.

  • 변경사항이 존재하는 모든 코드 스테이징하기

    git add .

  • 특정 폴더 또는 파일만 스테이징하기

    git add "특정 파일 또는 폴더명"
    // 확장자 포함 + 빈폴더는 불가

  • 모든 스테이징 취소하기

    git reset

  • 특정 폴더 또는 파일만 스테이징 취소하기

    git reset (특정 파일 또는 폴더명)

• 커밋( commit )하기 ( git의 핵심 기능 )

  • commit에 대해서

    • 스테이징이 끝난 코드들은 버전 관리를 위해 기록을 남겨야 하는데, 이 과정을 커밋이라고 한다.

    • 커밋을 통해 남기는 기록은 파일 및 폴더의 수정시간, 이전 커밋과 비교 후 변경 이력 등의 정보가 담기게 됨

    • git을 다룰 떄는 모든 작업을 커밋을 중심으로 생각해야 함

    • 따라서 보통 하나의 작업당 한 커밋만을 수행하는 것을 권장하며 커밋 메시지에는 작업한 내용이 드러나도록 해야한다.

      • 커밋 메시지 예시

        예시) 기능이 다른 파일 A와 B의 수정 작업을 진행할 때,

        • 나쁜 커밋 메시지 : "A B 수정"
        • 좋은 커밋 메시지 : "파일 A 수정 - #이슈번호, 파일 B 수정 - #이슈번호"

        --> 남과의 협업에서는 지킬 것을 권장함

  • 메시지를 포함한 커밋

    git commit -m "커밋 메시지"
    // 커밋 메시지 안에서는 엔터키를 사용한 줄바꾸기도 자유롭게 가능

  • 커밋 메시지 수정하기

    git commit --amend

  • 푸시 전에 커밋 취소하기

    • 푸시하기 전 가장 최근 커밋과 스테이징을 취소

      git reset --soft HEAD^

    • 해당 커밋번호 이후의 모든 커밋과 스테이징을 취소

      git reset --soft [커밋명^]

      --> 커밋명은 영문과 숫자로 이루어진 40자리 이름이 붙는데,
      깃에서 커밋을 조작할 때는 앞의 6자리만 떼어 사용해도 된다.
      예시) 977542ge2eegw666w5r2s1f5e8w95e2a1ssd5w6q --> 977542
      

파일 업로드 하기

• 푸쉬 ( push )

  • push란?

    • push는 내 commit 기록을 원격 저장소( remote repo, github 내의 저장소 )에 추가할 때 사용함

    • 원격 저장소 주소가 존재하지 않으면 푸시는 불가능
      ( 원격 저장소 주소는 github에 가입한 후, 원격 저장소를 생성,
      이후 해당 원격 저장소의 주소를 가져오면 된다. )

    • push 동작을 수행하면 로컬 저장소의 커밋 기록과 원격 저장소의 head보다 앞에 있을 때( 최신일 때 ) 푸시를 진행한다.

      

      --> push 시에는 원격 저장소의 head와 로컬 저장소의 커밋을 비교한다.

  • 특정 저장소 / 브랜치에 커밋 푸시하기

    git push [저장소명] [브랜치명]

  • 특정 저장소 / 브랜치에 강제로 커밋 푸시하기

    git push -f [저장소명] [브랜치명]
     // push -f 옵션은 원격 저장소를 로컬 저장소로 완전히 덮어씌움
     // --> 매우 위험한 옵션 ,, interactive rebase시에만 사용

  • 특정 저장소 / 브랜치를 기본 푸시 타켓으로 설정하고 푸시하기

    git push -u [저장소명] [브랜치명]
     // push -u 옵션을 사용하면 이후에는 저장소/브랜치를 직접 지정할 필요 없이 git push 명령만으로 지정한 위치에 푸시한다.

파일 내려와서 변경사항 적용하기

( 원격 저장소의 내용을 그대로 복사하여 붙여넣는 것이 아니라 merge(병합)을 통해 합쳐주는 개념 )

• 풀 ( pull )

  • pull 이란?

    • 원격 저장소의 변경된 내용을 로컬 저장소에 적용할 때 사용함

    • 좀 더 명확히 말하면 로컬 저장소에 있는 내 branch에 원격 저장소의 master branch의 내용을 더하여
      내 branch에 merge(병합)시키는 작업을 의미한다.

    • pull은 branch의 내용을 완전히 덮여씌운다는 개념보다는 없는 부분을 추가한다는 느낌이 좀 더 강하다.
      ( 물론 어느 부분이 추가되고 어느 부분이 지워지는지 단순하게 말하긴 힘들다. )

    • 일반적으로 원격 저장소에 push하기 전에 pull을 먼저하게 된다.
      그 이유는 master branch의 변경사항이 내 branch에 적용되지 않은 상태에서 master branch에 merge해버릴 경우 문제의 소지가 많기 때문이다.
      그래서 먼저 pull을 통해 내 branch에 master branch를 merge하여 변경사항들을 적용시켜준 다음에
      내용 충돌로 인한 Conflict 문제가 발생하는지 먼저 파악한 후, 발생했다면 문제를 해결한다. ( 다른 개발자가 merge한 내용과의 충돌 )
      최종적으로 push하여 master branch에 merge하여 올리게 된다.

  • master branch를 내 로컬 저장소의 branch에 pull 하기

    git pull origin master

• 패치 ( fetch )

  • pull처럼 원격 저장소의 커밋들을 로컬 저장소로 가져온다. 하지만 pull과 다르게 자동으로 Merge해주지 않는다.
    때문에 본인이 직접 확인한 후 Merge하는 과정을 거쳐야한다.

파일 다운로드

• github 사이트로 들어가서 직접 다운

  • https://github.com/
  • github 사이트로 들어가서 직접 다운로드하면 된다.

• 클론 ( clone )

  • clone은 해당 원격 저장소에 있는 내용을 내 로컬 저장소에 복제하는 명령이다.

    • 즉, 다운로드라고 보면된다.

  • clone을 통해 복제해오기

    git clone ( 다운로드할 파일에 대해 github의 Clone or download에 있는 주소 )