Git을 사용하기 전 알아야 할 것
Kernel : 하드웨어와 응용프로그램을 이어주는 운영체제의 핵심 소프트웨어
Shell : 운영체제의 커널과 사용자를 이어주는 소프트웨어
- sh(Bourne Shell) : AT&T Bell 연구소와 Steve Bourne이 작성한 Unix Shell
- csh : 버클리의 Bill joy가 작성한 Unix Shell
- bash(Bourne Again Shell) : Brian fox가 작성한 Unix Shell
- 다양한 운영체제에서 기본 쉘로 채택
- zsh : Paul Falstad가 작성한 Unix Shell
- sh 확장형 Shell
- 현재까지 가장 완벽한 Shell
Basic Shell Command
- cd : 작업중인 디렉토리를 변경
- pwd : 현재 위치한 디렉토리 출력
- ls : 현재 위치한 디렉토리에 있는 파일, 디렉토리 리스트 출력
- mkdir : 디렉토리 생성
- touch : 파일 생성
- rm : 파일 삭제 (옵션에 따라 디렉토리도 삭제 가능)
- rmdir : 디렉토리 삭제(디렉토리 내부에 아무것도 없어야 함)
- mv : 파일 이동
- cat : 파일의 내용을 화면에 출력
- vi : vim editor를 통해 파일 내용 작성
Basic Vim Command
- h j k l : 왼쪽, 위, 아래, 오른쪽으로 커서 이동
- i : Normal mode에서 Insert mode로 변경
- v : Normal mode에서 vitual mode로 변경
- ESC : Normal mode로 변경
- d : 삭제
- dd : 한 줄 삭제
- y : 복사
- y : 한 줄 복사
- p : 붙여넣기
- u : 실행 취소
- a : 현재 커서 뒤에 삽입
- aa : 줄 맨 끝에 삽입
- o : 현재 커서 행 아래에 삽입
- O : 현재 커서 행 위에 삽입
- H : 화면 맨 위로 이동
- L : 화면 맨 아래로 이동
command mode인 경우
- :q : 나가기
- :q! : 저장하지 않고 나가기
- :w : 저장
- :wq : 저장하고 나가기
- :{number} : number행으로 이동
Git
git이란?
- 분산형 버전 관리 시스템 (Vision Control System)
git의 특징
- 빠른 속도, 단순한 구조
- 분산형 저장소 지원
- 비선형적 개발 가능 (수 천개의 branch를 사용 가능)
git의 장점
- 소스코드 주고받기 없이 동시작업이 가능하여 생산성이 증가한다.
- 수정내용은 commit 단위로 관리,배포 뿐 아니라 원하는 시점으로 checkout이 가능하다.
- 새로운 기능 추가는 branch로 개발하여 편안한 실험이 가능하다.
- branch에서 성공적으로 개발이 완료되면 merge하여 반영할 수 있다.
- 인터넷이 연결되어 있지 않아도 개발이 가능하다.
- 누가 프로그램 개발에 얼마나 기여했는지 볼 수 있다.
- 의도적으로 작업을 방해하는 행위를 방지할 수 있다.
git의 process flow
-
작업중인 프로젝트의 디렉토리에서 작업한 파일을 add.
-
add된 파일은 staging area에 모임
-
staging area에 모인 파일을 commit하면 로컬 저장소에 저장되어 기존의 파일이 작업한 파일로 변경되고
-
push하면 로컬 저장소의 변경 내용이 원격 저장소에 반영된다.
왜 Staging area를 사용하는가?
- 한번에 많은 작업을 해도 일부분만 commit할 수 있다.
- 작업한 내용이 충돌한 경우, 충돌을 해소하는 동안 작업 데이터를 안정적으로 사용할 수 있다
- 충돌한 부분만 해소하고 commit할 수 있어서 편리하다.
- commit을 다시할 때, 메시지 로그 뿐만 아니라 파일 내용까지 고치고 싶을 때 유용하게 사용할 수 있다.
Conventional commits
- 커밋 메시지에 곁들어진 가벼운 컨벤션으로 명확한 커밋 히스토리를 생성하기 위한 간단한 규칙
- 이렇게 만들어진 커밋 히스토리를 이용하여 더 쉽게 자동화된 도구를 만들 수 있음
- 컨벤션 메시지에는 다음과 같은 prefix를 넣어주는 것이 중요
(팀 규칙에 따라 달라질 수 있음)- feat : 기능 개발 관련
- fix : 오류 개선 혹은 버그 패치
- docs : 문서화 작업
- test : test 관련
- conf : 환경설정 관련
- build : 빌드 관련
- ci : Continuous Integration 관련
commit할 때 기억해야 하는 것
- commit은 동작 가능한 최소단위로 자주 할 것
- 해당 작업단위에 수행된 모든 파일 변화가 해당 commit에 포함되어야 함.
- 모두가 이해할 수 있는 commit log를 작성할 것
- Open Source Contribution시 영어가 강제되지만, 그렇지 않을 경우 팀 내 사용 언어를 따라 쓸 것.
- 제목은 축약하여 쓰되(50자 이내), 내용은 문장형으로 작성하여 추가 설명할 것.
- 제목과 내용은 한 줄 띄워 분리할 것.
- 내용은 이 commit의 구성과 의도를 충실히 작성할 것.
.gitignore
- git이 파일을 추적할 때, 어떤 파일이나 폴더 등을 추적하지 않도록 명시하기 위해 작성하며, 해당 문서에 작성된 리스트는 수정사항이 발생해도 git이 무시하게 된다.
- 특정 파일 확장자나 이름에 패턴이 존재하는 경우, 특정 디렉토리 아래의 모든 파일을 무시할 수 있다.
License
-
오픈소스 프로젝트에서 가장 중요한 라이센스는 내가 만들 때에도, 배포할 때에도 가장 신경써야 하는 것 중 하나이다.
-
MIT License
- MIT에서 만든 라이센스로, 모든 행동에 제약이 없으며 저작권자는 소프트웨어와 관련한 책임에서 자유롭다.
-
Apache License 2.0
- Apache 재단이 만든 라이센스로, 특허권 관련 내용이 포함되어 있다.
-
GNU General Pulbic License v3.0
- 가장 많이 알려져 있으며, 해당 라이센스가 적용된 소스코드 사용시 GPL을 따라야 한다는 의무사항이 존재한다.
Rename
파일의 이름을 변경하는 경우 $mv a b 이런 식으로 명령어를 사용한다. 이렇게 이름을 변경하면 우리 눈에는 파일이름이 잘 변경된 것으로 보이겠지만 $git status 명령어를 사용해보면 문제가 생긴 것을 알 수있다.
git에서 a파일이 삭제 되고, b라는 파일이 새로 생성된것으로 트래킹하기 때문이다.
때문에 $git mv a b 방식으로 rename해야 git에서 제대로 파일 이름을 변경한 것을 트래킹 할 수 있다.
stage area에 올라가 있는 파일을 내리는 방법
$git reset HEAD {filename}
$git rm -f {filename} : 내리고 삭제까지
commit을 수정하는 방법
$git commit --amend
#git rebase -i <commit>미완성된 기능을 잘못 commit한 경우 어떻게 해야 할까?
- 최악의 경우는 $git reset 명령어를 통해 commit을 지우는 경우이다.
commit을 억지로 지우더라도 다른 협업하는 동료의 clone repo에 존재하는 commit log로 인해 파일이 살아나거나, 과거 이력이 깔끔하게 사라져 commit log tracking이 힘들어 질 수 있다.
그럼 어떻게 하는 것이 좋은가?
- $git revert --no-commit 명령어를 통해 잘못하기 전 과거로 돌아가 최신을 유지하면서 되돌렸다는 이력을 commit 으로 남기는 것이 모든 팀원들이 이 사항을 공유하고 주지시킬 수 있다.
- commit을 따로 안할땐 --no-edit을 붙인다.
- merge commit을 되돌릴 땐, -m($git revert -m{1 or 2} {merge commit id})
후기
기본적인 사용법이나 라이센스는 학부생 때 배워서 알고 있었지만 프로세스의 자세한 흐름, 현업에서 어떻게 쓰이고 어떤 규칙을 잘 지키는 것이 중요한 지에 대해서는 잘 몰랐는데 강의를 통해 자세히 알게 되어 유용했다.
애매하게 알고 있는 지식을 재정립하는데 도움이 많이 되었고 여러 실습과 반복을 통해 git의 사용법을 더 정확하게 알 수 있었다.
github : https://github.com/kiaeh2323 , email : kiaeh9269@gmail.com