Git, Github

git은 분산 버전 관리 시스템(Version Control System)이다. git을 사용하면 동료들과 협업하기가 매우 수월해지고 버전을 관리하는데 용이하다

git을 사용하기 전에 설정을 하고 보다 정확하고 편리하게 사용하자!

1. git config --global user.name "name"
2. git config --global user.email "email"
3. git config --global core.pager "cat"
4. git config --global core.editor "vim"
5. git config --list로 제대로 설정이 되었는지 확인하기

user.email=gghkdu2@gmail.com
user.name=JJongBin
core.editor=vim
core.pager=cat

config를 수정한 부분이 정상적으로 수정되었는지 확인한다!

▶️ 정방향으로 git을 사용하는 방법

1. git init

사용자가 remote repository까지 밀어넣는법은 다음과 같다

1. git init: 현재 폴더를 git을 사용할 수 있도록 만든다
2. git branch -M main: git의 branch가 master에서 main으로 변경되었기 때문에 branch를 main으로 변경한다
3. git remote add [alias] [repository 주소]: 사용자의 git 저장소와 연결시켜준다
4. 파일을 작업한 후에 git add [file-name]으로 stage에 파일을 올려준다
5. git commit: local repository로 stage에 있는 파일을 commit message와 함께 올려준다
6. git push origin main: remote repository로 commit 된 내역들을 밀어넣는다 이때 만약 commit이 처음 이라면 싱크를 맞춰주기 위해 -u flag를 사용한다

2. clone

git페이지에서 저장소를 생성한 후에 주소를 복사하고 다음의 명령어를 입력한다

git clone [repository주소]

이하 과정은 remote 이후의 과정과 동일하다!

- 참고

추가적으로 권장하지 않는 사항이 있다

1. git add .: 모든 파일들이 모두 stage로 올라가기 때문에 관리 측면에서 어렵고 꼬일 수 있는 경우가 많다
2. git commit -m "": 간단하게 vi를 이용하지 않고 commit message를 작성할 수 있는 방법이지만 여러줄을 이용해서 제목, 내용을 commit message로 작성하는 것을 권장하고, 여러줄을 작성할때 -m을 사용한 commit은 이전줄의 수정이 어렵기 때문에 처음부터 다시 해야될 수 있다

▶️ commit 작성 요령

1. 영어로 commit message를 작성한다
2. commit 제목만 보고도 작업의 유형을 유추할 수 있도록 적어주는 것이 좋다
3. 작업단위가 다른 경우에는 commit을 따로 해줘야한다
4. commit의 제목은 40자를 넘기지 않도록 한다
5. 제목과 내용 사이에는 한줄의 공간을 준다

commit message의 첫 부분에 type을 명시하는 것이 좋다고 하는데 어떤 작업을 했는지 유추할 수 있기 때문이다 type은 다음과 같이 정해져있다

type	설명
feat	새로운 기능에 대한 커밋
fix	버그 수정에 대한 커밋
build	빌드 관련 파일 수정에 대한 커밋
chore	그 외 자잘한 수정에 대한 커밋
ci	CI관련 설정 수정에 대한 커밋
docs	문서 수정에 대한 커밋
style	코드 스타일 혹은 포맷 등에 관한 커밋
refactor	코드 리팩토링에 대한 커밋
test	테스트 코드 수정에 대한 커밋

▶️ commit 시 주의 사항

1. 동작하는 최소단위로 커밋한다 -> 동작한다는 것을 전제로 하고 있기 때문에
2. 영어를 사용해서 commit message를 작성한다
3. 제목은 축약, 내용은 문장형으로 작성한다
4. 내용에서는 제목에서 작성하지 못한 세부적인 부분을 작성한다

▶️ README.md

프로젝트와 저장소를 설명하는 문서로 repository를 보는 다른 사람들을 위한 표지의 역할을 한다

▶️ .gitignire

.gitignore는 git에 올리지 않도록 하는 역할을 한다. 폴더나 파일명을 적어주면 된다

쉽게 작성할 수 있는 사이트: https://gitignore.io

▶️ LICENSE

많이 사용되는 라이센스는 다음과 같다

• MIT License: 오픈소스로 자유롭게 사용
• Apache License2.0: 무료로 사용해도 되지만 소유권을 주장할 수 있다
• GNU General Public License v3.0: 해당 코드를 참조하면 GNU가 됨 -> 의무적(MIT로 풀 수 없다)

만약 무엇이든 가져다 사용하는 경우가 있는 경우 라이센스를 확인해야한다 (라이센스가 보이지 않아도 메일을 보내는 등 꼭! 확인해봐야 한다)

▶️ branch

git은 동일한 코드를 다른 동료들과 함께 공유하고 다룰 수 있는데 branch라는 개념이 있기 때문이다 branch는 가지라는 뜻으로 현재 줄기에서 가지를 새로 뻗는다고 생각하면 된다

현재 git은 main branch를 사용한다 이 main에서 새로운 branch를 생성하여(branch를 친다라고 한다) 수정하고 merge해서 main에 반영할 수 있다

1. git branch [branch-name]으로 새로운 branch를 생성한다
2. 아직 현재 branch는 main이므로 새로운 branch로 이동해줘야 한다 → git switch [branch-name] or git checkout [branch-name]

만약 새로운 branch에서 파일을 수정하고 merge하기전에 기존의 main에서 수정한 파일이 수정되어 있다면 무언가 잘못된 것이다 → 각각의 branch에서 작업한 내용은 merge하기전에 반영되지 않는다

▶️ merge

별도의 branch에서 파일을 작성하거나, 수정하고 기존의 branch로 반영하기 위해서는 git merge [branch-name]라는 명령어를 이용한다

기존의 branch에서 별도의 branch에서 수정한 파일을 동시에 수정하지 않았다면 그냥 병합된다

하지만 동시에 똑같은 파일을 수정했을 경우를 충돌했다고 하는데 협의 후 진행하도록 기존 branch의 파일 내용과 별도 branch의 파일 내용이 같이 존재하는 파일이 생성된다

test.py파일을 생성하고, 새로운 branch를 만들어서 테스트해봤다

• main branch test.py

  print("This is main branch!!!")
  

• stem branch test.py

  print("This is stem branch!")
  

git merge stem을 한 결과 다음과 같은 메세지를 볼 수 있었다

Auto-merging test.py
CONFLICT (content): Merge conflict in test.py
Automatic merge failed; fix conflicts and then commit the result.

merging이라는 메세지를 보니 merge가 아직 진행중이며 완료되지 않았음을 알 수 있었다

main의 test.py를 보면 다음과 같다

<<<<<<< HEAD
print("This is main branch!!!")
=======
print("This is stem branch!")
>>>>>>> stem

두 파일이 합쳐져있었다 여기서 협의를 해서 최종적인 코드를 작성하면 된다

print("This is main branch but stem plused main branch!")

이후 add, commit , push 해주면 정상적으로 remote repository에 반영이 된다

▶️ git flow

git을 이용해 여러명이 개발을 할때 거의 표준처럼 사용되는 방법이다

git flow에서는 branch를 5가지를 사용한다

branch	설명
main	기준이 되는 브랜치로 제품을 배포하는 브랜치
develop	개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합친다
feature	단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합친다
release	배포를 위해 main 브랜치로 보내기 전에 먼저 검사 하기위한 브랜치
hotfix	main 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치

git flow를 하기 위해서는 준비가 필요하다

macos의 경우 다음의 명령어를 이용해서 git-flow를 다운받는다(brew를 이용하므로 brew 필요!) brew install git-flow-avh

window의 경우 git bash를 이용하는 경우 받지 않아도 된다

참고 https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

- feature

feature는 개발하기 위한 branch이다

Git flow feature start [branch 이름]		// branch를 생성하고 해당 branch로 이동
Git flow feature finish [branch 이름]	  // branch를 종료하고 원래 branch로 이동

기존에는 branch를 생성하고 switch를 이용해서 이동까지 해야하지만 자동으로 해준다

이렇게 생성된 branch는 feature/입력한 branch이름이 된다

만약 잘못 생성한 경우 main branch로 이동한 후 해당 branch를 삭제해주면 된다 (git branch -D [branch-name])

- release

relaese는 main으로 반영하기 전에 검사를 할 수 있는 branch이다

Git flow release start  [버전]
Git flow release finish [버전]

finish를 하게 되면 세번의 vi을 마주하게 된다 첫번째는 main, 두번째는 release note(tag) 세번째는 develop에 반영이 되는 commit이다

이후 각각 main, develop, tag에 push를 해주면 된다

git push origin main
git push origin develop
git push --tag

# 버전의 표현

버전은 보통 v0.0.0 처럼 표현한다 만약 다음과 같이 세자리로 구성되어 있다면

Release Number . Major Number . Minor Number

• Release Number: 1로 시작해서 큰 변화가 발생했을 때 이 수치를 올린다
• Major Number: 0으로 시작해서 주요 기능의 추가나 변경 등 사용상 혹은 컨텐츠의 주요 변화가 발생했을 때 1 또는 무작위로 증가한다. 간혹 알파벳이 붙기도 하는데 예를 들어 Beta(테스트버전)의 경우 b를 숫자 뒤에 붙이는 경향이 있다.
• Minor Number: 0으로 시작해서 버그 수정 등 미미한 변화가 발생하면 1씩 혹은 무작위로 증가한다. 역시 개발사 정책에 따라 특정 알파벳이 붙을 수도 있다.