ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • GIt
    코드잇 부스트 2024. 8. 5. 18:45

    Git 시작하기

    Git이란?

    Git은 프로그래머의 협업 및 버전 관리를 위한 툴이다.

    개발자라면 필수적으로 사용할 수 있어야 한다.

    GitHub란?

    Git은 버전 관리를 할 수 있는 툴이고,

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

    Git 써보기

    repository와 commit

    Repository: 프로젝트 디렉토리가 버전(변경사항)별로 저장된다.

    Commit: 프로젝트 디렉토리의 특정 모습을 하나의 버전으로 남기는 행위

    repository 만들기

    디렉토리 안에서 git init을 통해 깃에 연결할 수 있다.

    연결되면 .git이라는 디렉토리가 내부에 생성된다.

    첫 commit 해보기

    git config user.name "qktjwl123"
    git config user.email "qktjwl123@gmail.com"

    git에 커밋을 하기 위해 사용자를 설정한다.

    git add "파일 이름"

    commit에 반영할 파일을 추가해준다

    git commit -m "커밋메시지"

    커밋 메시지를 입력해준다.

    Git의 3가지 작업 영역

    1. working directory
      1. 작업을 하는 프로젝트 디렉토리
    2. staging area
      1. git add를 한 파일들이 존재하는 영역
    3. repository
      1. working directory의 변경 이력들이 저장되어 있는 영역
      2. .git 디렉토리가 Repository이다.

    git add 더 자세히 알아보기

    git status

    위 코드로 staging area의 변경 사항을 확인할 수 있다.

    git add .

    으로 한번에 변경된 모든 파일을 staging area에 추가해줄 수 있다.

    git이 보는 파일의 4가지 상태

    Git에서 파일들은 크게 다음 2가지 상태를 가짐

    • Untracked 상태
      • 이 상태는 파일이 Git에 의해서 그 변동사항이 전혀 추적되고 있지 않는 상태
      • 파일을 새로 생성하고 그 파일을 한 번도 git add 해주지 않았다면 이 상태
    • Tracked 상태
      • 파일이 Git에 의해 그 변동사항이 추적되고 있는 상태
      1. Staged 상태
        1. 파일의 내용이 수정되고나서, staging area에 올라와있는 상태
      2. Unmodified 상태
        1. 현재 파일의 내용이 최신 커밋의 모습과 같은 상태
      3. Modified 상태
        1. 최신 커밋의 모습에서 수정된 상태

    git add 취소하기

    git reset "파일명"

    staging area에 있는 파일을 제거한다.

    working directory의 내용은 변경되지 않는다.

    특정 git 커맨드의 사용법을 알고 싶다면?

    git help "커맨드"
    man git-"커맨드"

    커맨드의 사용법을 알 수 있다.

    GitHub 시작하기

    Local Repository를 Remote Repository로 보내기

        git remote add origin "레포지토리 주소"
        git push -u origin master

     

    위 코드로 연동 및 전송이 가능하다.

    username과 토큰을 입력해야한다.
        - 리모트 레포지토리: 깃허브의 레포지토리
        - 로컬 레포지토리: 내 컴퓨터의 레포지토리

    Local Repository에서 바뀐 내용을 Remote Repository에도 반영하기

    git push

     

    로컬의 커밋 내용은 위 명령어로 리모트로 올릴 수 있다.

    Remote Repository에서 바뀐 내용을 Local Repository에도 반영하기

    git pull

    위 코드로 원격 레포의 변경 사항을 가져온다.

    원격 레포는 협업 및 안정성 측면에서 의미를 갖는다.

    아무나 git push를 할 수 있는 건 아닙니다

    collaborator설정을 통해 push권한을 부여하고 협업자를 설정한다.

    다른 프로젝트 가져오기

    git clone "레포지토리 주소"

    깃허브의 explore탭에서 다른 사람들의 레포를 볼 수 있고 위 코드로 가져올 수 있다.

    오픈 소스 프로젝트란?

    소스 코드가 공개되어 있는 프로젝트를 **'오픈 소스 프로젝트(open source project)'**라고 한다.    
        - 그 소스 코드가 공개되어야 하고
        - 누구나 코드를 자유롭게 가져다가 사용할 수 있고
        - 원래의 코드를 자신이 원하는 대로 수정할 수 있어야한다

    리차드 스톨만에 의해 자유 소프트웨어 운동이 시작되어 소스 코드를 공유하는 문화가 생긴 것이다.
        
        open source license
        
        - 오픈 소스가 활용된 부분이 있는 코드라면 그 코드도 마찬가지로 오픈 소스로 공개해야 한다.
        - 기존의 오픈 소스 내용 중 조금 수정해서 사용한 부분이 있다면 그것을 표시하고 써야 한다.
        
        오픈 소스 프로젝트의 장점
        
        - 무료로 사용할 수 있다.
        - 여러 개발자들이 참여하기 때문에 폐쇄적으로 코드를 관리할 때보다 코드의 신뢰도가 더 높다.

          (이 부분은 사람마다 의견이 다를 수 있습니다)
        - 오픈 소스 프로젝트에 참여 중인 다른 개발자들에게 질문을 할 수 있다.
        - 어떤 프로그램을 개발할 때 특정 분야에서 사실상 표준처럼 사용되는 오픈 소스 프로그램을 많이 활용할수록 전체 개발 속도를 단축시킬 수 있다.
        
        **오픈 소스 프로젝트의 단점**
        
        - 참여자 수가 많지 않거나, 참여자의 실력이 좋지 않으면 소스 코드의 신뢰성을 보장하기 어렵다.
        - 해당 오픈 소스를 사용해서 문제가 생겼을 때 보상을 해주거나, 책임을 질 주체가 없다.
    - README.md를 더 예쁘게
        
        md확장자는 markdown의 줄임말이고 특정 규칙에 맞게, 간단한 텍스트만으로 어떤 표시를 해두면, 그것이 자동으로 HTML 태그로 전환되도록 약속된 문법이다.
        
        [**이 링크](https://ko.wikipedia.org/wiki/%EB%A7%88%ED%81%AC%EB%8B%A4%EC%9A%B4)에서 자세히 볼 수 있다.**
        
        [**이 링크](https://guides.github.com/features/mastering-markdown/)에선 깃허브에서 사용하는 마크다운 언어의 규칙을 볼 수 있다.**
        
        [**마크다운 관련 노트](https://www.codeit.kr/learn/courses/data-science/975)에선 코드잇에서 정리해둔 마크다운 노트를 볼 수 있다.**

     

    커밋 다루기

    • 커밋 히스토리 살펴보기
      • git log를 통해 커밋 내역을 볼 수 있다.커밋 아이디(해쉬)로 구분된다.위 코드로 해당 커밋과 이전 커밋의 차이를 볼 수 있다.-m옵션 없이 커밋만 하면 텍스트 에디터에 메시지를 남길 수 있다.
      • 복잡하고 긴 커밋 메시지의 경우 유용하다.
      • git commit
      • git show "깃해쉬"
      • 위로 올라갈 수록 최신 커밋이다.
      • git log [--pretty=oneline]
    • 최신 커밋 수정하기
      • 으로 가장 최근 커밋을 수정할 수 있다.
      • git commit --amend
    • 커밋 생성, 커밋 메시지 작성 가이드라인
      1. 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비운다.
      2. 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 않는다.
      3. 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성한다.
      4. 커밋 메시지의 제목은 명령조로 작성한다.(Fix it / Fixed it / Fixes it)
      5. 커밋의 상세 내용에는 이런 걸 적는다.
        • 왜 커밋을 했는지
        • 어떤 문제가 있었고
        • 적용한 해결책이 어떤 효과를 가지는지
      6. 최대한 친절하게 작성한다.
      7. 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남긴다.
      8. 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 한다.
      9. *여러 명이 참여하는 프로젝트의 경우 컨벤션을 만들어 준수해야한다.
    • 긴 커맨드에 alias 설정하기
      • Git에는 길이가 긴 경우의 커맨드 전체에 별명을 붙여서 그 별명을 사용할 수 있도록 해주는 기능이 있다.
      • 이 때 붙이는 별명을 alias라고 하고, 별명을 붙이는 행위를 aliasing이라고 한다.
      • git config alias.history 'log --pretty=oneline'
    • 두 커밋 간의 차이 보기
      • 두 커밋간 차이를 볼 수 있다
      • git diff "커밋아이디" "커밋아이디
    • HEAD의 의미
      • HEAD가 가르키는 커밋에 따라 working directory구성
      • HEAD 어떤 커밋 하나를 가리킴
    • 이전 커밋으로
      • git reset하기이전 커밋으로 돌아간다.
      • *이때 staging area에는 변동이 없다.
      • git reset --hard [커밋아이디]
    • git reset의 3가지 옵션
      • git reset [옵션] eea5 Working Directory Staging Area Repository
        --soft 안 바뀜 안 바뀜 HEAD가 eea5 커밋 가리킴
        --mixed 안 바뀜 eea5 커밋처럼 바뀜 HEAD가 eea5 커밋 가리킴
        --hard eea5 커밋처럼 바뀜 eea5 커밋처럼 바뀜 HEAD가 eea5 커밋 가리킴
    • HEAD를 기준으로 git reset하기
      • 바로 이전 커밋으로 리셋HEAD가 가리키는 커밋보다 2단계 전에 있는 커밋으로 리셋
      • git reset --hard HEAD~2
      • git reset --hard HEAD^
    • 커밋에 tag 달기
      • 중요한 커밋에는 커밋 메시지뿐만 아니라 **태그(tag)**라는 것을 추가적으로 달기도 한다.위 코드로 프로젝트 디렉토리에 있는 모든 태그를 조회할 수 있고,위 코드로 태그와 연결된 각 커밋을 볼 수 있다.
      • git show [태그 이름]
      • git tag
      • git tag [태그 이름] [커밋 아이디]

    브랜치 사용하기

    • 브랜치란?
      • 코드를 관리하는 관리 흐름이다.
Designed by Tistory.