Git & GitHub

박다현·2023년 5월 7일
0

likelion

목록 보기
6/23
post-thumbnail

01 객체지향 / 절차지향


객체지향 프로그래밍

객체지향 Object Oriented
실제 세계를 모델링하여 소프트웨어를 개발하는 방법

객체
보고 만질 수 있는 것 , 지성적으로 이해할 수 있는 것 , 생각이나 행동이 추구하는 바
개념상으로 존재하는 것 등 모든 것이 될 수 있음

특징

  • 캡슐화
    관련 데이터와 알고리즘(코드)이 하나의 묶음으로 정리된 것
    자바 > 필드와 메서드를 캡슐로 감싸 보호해 외부로부터의 접근 제한
    외부 세계와의 상호작용은 메소드 method 를 통하는 방법인데 라이브러리로 만들어 업그레이드 하면 쉽게 바꿀 수 있음

  • 상속
    상위 클래스의 모든 것을 하위 클래스가 물려받는 것 , 이미 작성된 클래스를 이어 받아 기존 코드 재활용해서 사용하는 것 의미 , 프로그램 쉽게 확장할 수 있도록 해주는 강력한 수단

  • 다형성
    같은 이름의 메서드가 클래스 혹은 객체에 따라 다르게 구현되는 것 , 하나의 이름(방법)으로 많은 상황에 대처하는 기법 , 개념적으로 동일한 작업을 하는 함수들에 똑같은 이름을 부여할 수 있으므로 코드 간단해짐

  • 추상화
    프로그램을 만드는데 필요한 부분만 파악/추출 필요 X -> 제거

장점

  • 재사용성
    상속을 이용해 코드 재사용

  • 생산성 증가
    객체지향 언어는 독립된 객체로 이루어져 있기 때문에 생산적으로 작업할 수 있고 유지보수 용이

  • 자연스러운 모델링
    객체는 세상에 존재하는 모든 것 , 객체지향 언어 자체가 우리가 살고 있는 세상과 닮아있다는 특징 존재 , 개발자가 생각하는대로 자연스럽게 구현 가능

단점

  • 처리 속도
    절차지향 프로그래밍보다 느림

  • 개발 속도
    난이도가 높아 객체의 역할과 기능을 이해해야만 프로그래밍 설계 가능

객체지향 언어

소프트웨어를 객체지향 방식으로 설계한 후 객체지향의 특성 ( 클래스, 객체, 상속, 추상화 등 ) 을 구현하는 데 사용되는 컴퓨터 프로그래밍 언어



절차지향 프로그래밍

절차지향 Procedural Oreinted

순차적 처리 방식 , 프로그램 전체가 유기적으로 연결되어야 함

과거에는 하드웨어와 소프트웨어의 개발 속도 차이가 크지 않았음 

but 소프트웨어 언어와 컴파일러의 발달로 하드웨어가 소프트웨어 따라오지 못하는 상황 발생

이러한 상황이 객체지향 언어의 등장을 이끌어 낸 것

장점

  • 처리 속도
    컴퓨터의 작업 처리 방식과 유사 -> 더 빨리 처리하는 것 가능

단점

  • 유지 보수 어려움
    구성 요소가 유기적으로 연결되어 있다는 것은 하나의 오류 발생할 시 , 전체 오류를 범할 수 있음을 의미 , 이는 문제를 해결할 때 일부분이 아닌 시스템 전체를 수리해야 함을 말함

  • 비효율적
    순서가 엄격해 코드 순서가 바뀌면 결과도 바뀔 우려 존재 , 언어의 융통성이 부족하여 생산 효율이 떨어짐

  • 보안성 낮음 , 상속 불가능

절차지향 언어

비교적 큰 문제의 해결에 쉽게 사용하도록 고안된 고급 언어



02 Git


Git
컴퓨터 프로그램 소스를 공유하고 협업하여 개발할 수 있는 버전 관리 시스템


장점

  • 버전 관리
    요구사항 반영 반복 > 코드 및 기능 수정
    전체가 다시 저장되는 것이 아닌 업데이트된 부분만 저장
    즉 , 불필요한 용량 차지를 줄이고 과거 버전의 코드로 되돌아갈 수 있음

  • 협업
    여러 명과 작업시 이메일이나 공유 드라이브로 소통하기엔 복잡 , 바로 업데이터가 되지 않고 코드를 가져오거나 에러가 발생할 경우 누가 어디를 잘못 건드렸는지 확인하기 불편함
    각자 코드 수정 > 만든 것을 합침 > 업무 효율 향상

  • 속도
    각각의 개발자들이 모두 분산 처리 서버의 주인이 되는 셈 , 서버가 직접 해야 될 일 감소

  • 분산 처리
    서버와 클라이언트 뿐인 기존 형상 관리에 비해 분산 처리 구조를 유연하게 세울 수 있음 , 중간 서버를 두거나 부서별로 따로 서버를 두는 등의 구성 자유도 증가

단점

  • 직관성
    기존 형상 관리 도구에 비해 덜 직관적이고 배우기 어려움 , 로컬 머신을 작업 공간 , 서버를 저장 공간으로 생각하면 더 이상 복잡한 개념 필요 없이 체크아웃 후 파일을 수정하고 다시 커밋하기만 하면 되는 중앙집중형 도구에 비해 다층구조를 갖고 있어 다른 계층과의 상호 작용 방식이 복잡하게 연결되어 있어 혼동을 유발할 가능성 증가

  • 다중 작업 불가능
    한 번에 여러 브랜치나 여러 태그에 걸쳐서 커밋 불가능 , 본인이 만든 사소한 변동 사항이 다른 브랜치에 자동적으로 알려지지 않고 나중에 취합하는 시점이 되어서야 반영 > 충돌의 원인이 될 수 있음

Git repository

  • 원격 저장소 remote repository
    파일이 원격 저장소 전용 서버에서 관리
    여러 사람과 함께 공유하기 위한 저장소 , 그 지역저장소와 연결되어서 동기화 되는 저장소

  • 로컬 저장소 local repository
    내 컴퓨터에 설치한 Git 과 연결할 저장소 , 실제로 Git 을 통해 버전 관리가 이뤄질 내 컴퓨터에 있는 폴더
    일시적인 서버 장애가 있어도 개발 지속적으로 가능 , 서버의 자료를 가져와 로컬에서 병합하고 이를 다시 올리는 형태로 병합 문제 발생 감소

Git Keyword

  • add
    commit 하기 전까지 스테이징 영역에 변경분을 모아놓는 작업
    명령어를 실행해도 Git 저장소의 변경 이력에 영향 X
$ git add [file name]

  • commit
    최종적으로 내 소스코드를 local 저장소에 작업 수행 내용 저장 ( 각 버전의 변경 사항 기록 ) , 문서 작성 중 저장과 동일한 것
    메세지가 없으면 commit 실행 X
1번째 줄 : 커밋 내의 변경 내용 요약
2번째 줄 : 빈 칸
3번째 줄 : 변경한 이유
$ git commit -m "커밋할 내용"

한 줄의 커밋 메세지를 입력해 vim 에디터를 띄우지 않고 커밋 가능
$ git commit -am "모든 파일을 커밋"

-am 옵션을 주면 git add . + git commit -m 한 것과 같은 기능

  • push
    local repository 에서 commit 한 작업을 repository 로 보내는 작업 , 내 소스코드 github 에 업로드
$ git push

  • fetch
    원격 저장소에서 새로 가져올 것이 있는지에 대한 여부 알려주는 기능
$ git fetch 

로컬에는 없지만 리모트 저장소에 있는 데이터 모두 가져옴

  • merge
    분기했던 브랜치를 main 브랜치에 합치는 작업
$ git merge 

  • pull
    remote repository 에서 local repository 로 업데이트
    원격 저장소에서 업데이트 된 내용이 있는지 확인하고 내 로컬 소스에 반영하는 기능
$ git pull 
$ git fetch
$ git merge


branch

독립적으로 어떤 작업을 진행하기 위한 개념

여러 사람이 동일한 소스 코드를 기반으로 서로 다른 작업을 할 때에
서로 다른 버전의 코드가 만들어질 수밖에 없는데 이러한 상황에
여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능을 수행

  • 브랜치 생성
git branch [branch name]
  • 브랜치 목록 확인
git branch
  • 브랜치 전환
git switch [branch name]

branch rule

  • Main branch
명명 규칙 : 보통 main 그대로 작성 

배포할 수 있는 브랜치 , 최종적인 상태를 의미하는 공간 > 최상위 브랜치

  • develop branch
명명 규칙 : 보통 develop 그대로 작성 

다음 출시 버전 개발하는 브랜치
ain에서 분기되어 기능 개발을 위한 브랜치들의 병합을 위해 사용 ( 기능 병합, 버그 수정 후 배포 가능한 상태가 되면 main 으로 병합 )

  • feature branch
명명 규칙 : feature / 기능 요약 

기능을 개발하는 브랜치
새 기능이나 버그 수정이 필요할 때마다 develop 브랜치에서 분기 ( 여기서의 작업은 공유할 필요가 없어서 주로 자신의 로컬 저장소에서 관리 )

  • release branch
명명 규칙 : release/X.X.X or release-X.X.X

이번 출시 버전을 준비하는 브랜치
feature 브랜치에서 기능 개발 후 develop 브랜치에서 병합을 하는 과정 반복 , 최종적인 버그 수정이나 문서 추가 등 실질적으로 release 하기 직전에 하는 단계를 위한 브랜치

  • hotfix branch
명명 규칙 : hotfix-X.X.X

출시 버전에서 발생한 버그를 수정하는 브랜치
갑작스럽게 수정해야 하는 경우에 main에서 수정하지 않고 hotfix 브랜치로 분기해 수정 후 main 으로 병합 ( main 에서 다시 배포 후에는 develop 브랜치에도 병합 )



03 GitHub


GitHub

Git에 프로젝트 관리 지원 기능을 확장하여 제공하는 웹 호스팅 서비스
Git 의 기본 기능을 포함하여 프로젝트 관리에 필요한 버그 추적 (bug tracking) , 기능 요청 (feature requests) , 작업 관리 (task management) , 위키 (wiki) 기능 등을 추가적으로 제공

GitHub 사용하는 이유

  • 무료
    Git 으로 관리하는 모든 코드들과 프로젝트를 GitHub에 무료로 전송해서 저장 가능
    비공개로 올릴 때만 유료 , github 말고도 다른 서비스가 많이 있지만 가장 널리 이용함

  • 분산형 버전 관리 시스템 DVCS
    클라이언트가 저장소를 통째로 복제하여 사용하기 때문에 서버에 문제가 발생해도 클라이언트는 복제된 저장소를 다시 서버에 복사하여 서버 내 데이터 복원 가능



객체지향 / 절차지향 그리고 Git / GitHub 에 관한 기본적인 내용을 정리하며 스터디 진행


0개의 댓글