Post

SW공학_2

Posted
By JunStiN 10 min read

asd

SW 공학 - GIT



🌀Git

  • 분산 버전 관리 시스템으로서, 소스 코드의 변경사항을 추적하는데 사용
  • 로컬 시스템과 원격 시스템을 두어, 로컬에서 작업 후 원격공간과 동기화
  • 주요 명령어에는 add, commit, push, merge, branch, checkout 등
  • 브랜치(branch) 기능을 통해 여러 개발자가 동시에 개발하면서도 충돌 없이 작업
  • git은 리눅스 토르발즈에 의해 개발된 이후 오픈소스프로젝트에서 관리



🌀Github

  • Github 소스코드가 온라인에서 관리되고 협업할 수 있는 플랫폼
  • 즉, Github은 Git의 리포지토리를 온라인상에서 관리하기 위한 플랫폼
  • Github -> 마이크로소프트에서 인수


  • oauth 토근 + 클론 (private repo)
    • git clone https://토큰정보:x-oauth-basic@git주소

Git 프로젝트 생성 및 수정절차

  • 신규 프로젝트 생성시
    • 방법1
      • git clone 레포주소

      • 해당 폴더로 이동해서 작업 시작


    • 방법2
      • 로컬 컴퓨터에서부터 이미 개발된 프로젝트가 존재시
      • git init
        • .git 컴파일 생성
        • .git 폴더가 위치한 곳에서 git config –list를 통해 컨피그 정보 조회
      • git remote add origin 레포주소
        • origin이란, 깃허브 저장소 주소를 의미(원격저장소)
      • git remote set url origin
        • url변경후 main에 push하면 main의 커밋 이력과 함께 업로드
      • git remote remove origin


  • 모든 이력 push
    • git push -all origin
      • 모든 브렌치의 커밋이력 push


github 사용자 지정

  • 사용자 지정은 사용자 인증과 상관없이 자유롭게 가능
  • 전역적 선언
    • git config –global user.name 깃허브아이디
    • git config –global user.email 깃허브이메일
    • 홈 디렉터리 .gitconfig 저장


  • 지역적 선언
    • git config –local 으로 선언
    • .git/config 저장



git 기본 명령어

  • git status
    • 현재 작업 디텍터리와 스테이징 에어리어 상태를 보여줌
  • git add
    • staging area로 업로드
    • git status로 확인
  • git commit -m “first commit”
    • local repo 업로드 및 커밋이력 생성
    • git commit -m “제목” -m “내용”
    • git log로 이력 확인
    • git commit만 치면 메시지 입력모드로 전환되고, 첫줄 제목 + 두번째 줄 부터 내용
  • git commit -am “메시지”
    • add와 커밋을 동시에

git pull 과 충돌

  • 수정후 수정사항 업로드
    • add, commit, push
  • origin이 수정되어 로컬과의 차이 발생시
    • origin의 변경사항은 로컬에서는 추적 불가능 -> 소스 컨트롤의 변경사항 인지는 로컬 레포지토리에 대한 변경인지
  • git pull origin main
    • origin을 기준으로 로컬을 업데이트
    • pull은 working 디덱터리까지 반영
    • 별도의 브랜치명 명시 안하면 현재 체크아웃 된 브랜치에서 pull
    • git pull origin main(브랜치명)
    • 만약 로컬의 변경파일과 origin의 변경파일이 같이 변경되면 충돌발생 가능성

git 취소 상황

  • 특정 스탭까지의 저장 사항을 취소
    • woring dir 수정사항 취소
    • add 후 취소
    • commit 이후 취소
    • push 후 origin까지 배포된 사항 취소
  • working dir 의 수정사항 취소
    • git checkout
      • 파일 수정사항의 취소
    • git clean -fdx
      • 파일을 신규추가 한 경우의 취소
    • git checkout . && git clean -fdx
      • 수정 및 추가 모두 취소
    • 개발IDE 사용시 쉽게 수정사항 취소 가능
    • add 이후 취소
      • text2.txt 신규 생성
      • git status -> untracked file
      • git add . -> git status -> Changes to be commited
      • git add 취소
        • git reset 또는 git restore -staged
      • commit 이후 취소
        • git reset HEAD^
          • unstged 상태로 만듬
        • git reset –soft HEAD~1
          • stged 상태 유지
      • push 후 origin까지 배포된 사항 취소
        • git revert 커밋id
        • 특정 커밋버전을 취소시키는 새로운 commit을 생성 후에 다시 push

git diff 와 fetch

  • git diff
    • 현재 작업 디텍터리와 스테이징 영역 사이의 차이점
  • git diff commmit1 commmit2
    • 두 커밋간 차이점 비교
    • commmit1 기준으로 commit2와의 비교시 차이점 출력
  • git diff main origin/main
    • 로컬 레포지터리의 메인과 오리진 메인과의 비교
  • git fetch origin main
    • 현재 체크아웃 되어있는 main과 origin main과의 차이가 있을 경우 차이점을 담은 참조데이터 fetch_head라는 곳에 생성
    • 차이점을 참고하여 일단 merge 후에 파일수정하고 다시 push

git stash

  • 작업 중단 변경사항을 임시로 저장하고 나중에 다시 적용할 수 있게 해주는 명령어
  • git stash init
    • 작업저장 목록
  • git stash show 인덱스
    • 복사본 내용 조회
  • git stash pop
    • 작업목록에서 제거하면서 저장사항 적용
  • git stash apply
    • 작업목록에서 유지하면서 적용

git tag

  • mian브랜치에서 tag를 붙여 버전을 명시하고, release 할 때 아래와 같이 tag를 붙인뒤 push
  • release에는 소스코드가 압축파일로 생성


  • 관련 명령어
    • git tag 버전명
    • git push origin 버전명
    • add, commit, push 와는 별도로 진행

feature branch 작업

  • 실제 현업에서 branch1, branch1, dev, main 등 여러 브랜치로 관리
    • 브랜치란 버전과는 다르게 개발의 경로를 의미
    • 일반적으로 production 관련 브랜치는 main, 개발용 브랜치는 dev
    • 나머지는 task별로 기능별로 개별적으로 만들어 사용 -> feature브랜치라 정함
    • feature 브랜치에서 작업 후 origin/feature로 푸쉬
    • Pull Request를 통해 dev까지 merge
    • dev에서 main으로 최종 merge


  • 주요 명령어
    • git fetch origin
      • 모든 브랜치 정보 fetch
    • git branch
      • 현재 저장소에 있는 모든 브랜치 목록
    • git branch 브랜치명
      • 브랜치명으로 새로운 브랜치를 생성하는 명령어
      • 기존에 checkout 되어 있는 브랜치를 기준으로

merge 전략

  • 브랜치에서 dev로 PR을 만든 뒤 merge하는 상황

  • merge / rebase / squash

    • merge
      • merge 두 브랜치의 변경 사항을 통합하는 기본적인 방법
      • branch1에서 넘어온 커밋ID와 신규 머지 커밋ID가 dev에 남게 됨
    • rebase
      • 한 브랜치의 커밋을 다른 브랜치의 최신 커밋에 “재적용”하는 방식
      • 이때에는 브랜치에서 넘어온 커밋ID가 아닌, 새로운 커밋ID가 발급되어 dev브랜치 생성
      • merge 커밋ID 남지 않게 되어, 깔끔한 커밋관리가 되나 이후에 branch1에서 다시 merge를 할 때 충돌이 발생하므로, 사용하던 branch1은 더이상 사용이 어려움.
    • squash
      • squash는 여러 커밋을 하나의 커밋으로 합치는 과정
      • local repository에서 여러 커밋을 발생시켰을 때 해당 커밋ID를 통합하여 하나의 커밋ID만들어 dev에는 하나의 커밋ID로만 이력 생성
    • rebase, squash는 feachre에서 dev브랜치로 merge할때에는 선택에 따라 가능하나, dev에서 main에 merge할때는 부적절
개발, SW공학
sw
This post is licensed under CC BY 4.0 by the author.