GIT

Version Control System(VCS)

 

GIt의 특징

• 빠른 속도, 단순한 구조
• 분산형 저장소 지원
• 비선형적 개발(수천개의 브랜치) 가능
• 소스코드 주고받기 없이 동시작업 가능 -> 생산성 증가
• Branch로 편안한 실험이 가능
• 인터넷이 연결되지 않아도 개발할 수 있음
• 실험후 성공시 Merge하여 반영
• 수정내용을 commit단위로 관리,배포뿐 아니라 원하느 시점으로 Checkout 가능
• cheout -> switch로 용어가 바뀜(둘다 알아두기)

GUI를 이용하는 방법

• git GUI
• sourcetree
• kraken
• smartgit

CLI 커맨드를 이용하는 방법은 필수로 알아야 함

 

 

Git objects

• Blob : 파일 하나의 내용에 대한 정보 (ex.사진 피사체)
• Tree: Blob이나 subtree 메타데이터(디렉토리 위치, 속성, 이름) (ex.사진의 메타정보)
• Commit: 커밋 순간의 스냅샷

 

깃의 흐름

워킹디렉토리 ->(add) stageing area -> (git commit)local repository ->(git push) remote repository

인터넷이 안될경우 commit으로 데이터를 쌓아놨다가 인터넷이 될 때 Push하면 commit시간기준으로 데이터가 올라감

remote reopsotiry ->(git pull) local repository

 

add: 앞접시

 

git != github

깃헙은 깃이라는 기술을 이용한 서비스

 

Cloud Remote Repository 서비스

• Github: 가장 유명한 서비스 (microsoft)
• Bitbucket
• GitLab

윈도우에서 사용할 때는 gitforwindows.org 사용 추천

 

 

Conventional Commits 과 커밋 주의사항 (파란글자는 Convention)

1. commit의 제목은 commit을 설명하는 하나의 구나 절로 완성
2. importanceofcapitalize Importance of Capitalize (띄어쓰기, 대문자규칙)
3. commit은 동작 가능한 최소단위로 자주 할 것.
4. 해당 작업단위에 수행된 모든 파일 변화가 해당 commit에 포함되어야 함.
5. 모두가 이해할 수 있는 log를 작성할 것.
6. Open Source Contribution시 영어가 강제되지만, 그렇지 않을 경우 팀 내 사용 언어를 따라 쓸 것.
7.  제목은 축약하여 쓰되(50자 이내), 내용은 문장형으로 작성하여 추가설명 할 것. 제목과 내용은 한 줄 띄워 분리할 것.내용은 이 commit의 구성과 의도를 충실히 작성할 것.
8. 팀마다 다를 수 있으니 관련 문서를 참조할 것.
9. 영어로 쓰는 것이 좋다. 제목만큼은 영어로!
10. prefix 꼭 달기
    feat: 기능 개발 관련
    fix: 오류 개선 혹은 버그 패치 docs: 문서화 작업
    docs:문서화 작업
    refactor:리팩로팅
    test: test 관련
    conf: 환경설정 관련
    build: 빌드 관련
    ci: Continuous Integration 
11. ref: https://www.conventionalcommits.org/ko/v1.0.0/
12. 예시
    1. (git add 후 git commit을 치면 vim으로 들어간다; vim이 아닐경우 git config --list 에서 조회해보고 수정하면됨)
    2. vim에서 첫줄에 prefix와 제목을 작성후 한줄공백띄우고 본문쓰면 됨
    3. wq로 저장하고 나오면 커밋됨
    4. 또는 git commit -m "제목 내용"을 써도된다. 엔터도 동일하게 들어가지만 쓰는중간에 다시 쓰려면 지우고 다시 써야함
    5. m플래그는 비추 또한 a플래그도 안쓰는 것이 더 좋다. (git add .도)
    6. 이전의 커밋내용을 수정하려면 git commit --amend로 하면됨

feat: Add server.py
fix: Fix Typo server.py
docs: Add README.md, LICENSE
conf: Create .env, .gitignore, dockerfile
BREAKING CHANGE: Drop Support /api/v1
refactor: Refactor user classes

 

 

 

Git ignore

• gitignore.io 사이트에서 키워드 넣으면 자동으로 생성해줌
• 작업중 맨처음 해야하는 일
•  
•  .gitignore 는 git이 파일을 추적할 때, 어떤 파일이나 폴더 등을 추적하지 않도록 명시하기 위해 작성하며, 해당 문서에 작성된 리스트는 수정사항이 발생해도 git이 무시하게 됩니 다. 특정 파일 확장자를 무시하거나 이름에 패턴이 존재하는 경우, 또는 특정 디렉토리 아래 의 모든 파일을 무시할 수 있습니다.
•  .gitattributes: 파일단위, 디렉토리 별 다른 설정을 부여하고 싶을 경우 아래참고
• 아래의 binary는 글자가 아니라 바이너리라는 뜻, 다른사람이 볼때 깨질수 있으니
• reference: https://thoughtbot.com/blog/xcode-and-git-bridging-the-gap

# Avoid conflicts in pbxproj files(iOS Project)
*.pbxproj binary merge=union

 

 README.md

•  프로젝트와 Repository를 설명하는 책의 표지와 같은 문서 나와 동료, 이 repo의 사용자를 위한 문서
•  예시

# Project Name
Abstract your project in few lines.
see [project sample page](project link)
## Documentation
### Installation
To install,
`$ pip install sesame`
and run `$ python open_sesame.py`
### Supported Python versions
`>=3.6`
### More Information
- [API docs]()
- [Official website]()
### Contributing
Please see [CONTRIBUTING.md]()
### License
Sesame is Free software, and may be redistributed under the terms of specified in the [LICENSE]() file.

 

 

LICENSE

오픈소스 프로젝트에서 가장 중요한 License는 내가 만들 때에도, 배포할 때에도 가장 신경써 야 하는 일 중 하나입니다.

가장 많이 사용하는 License는 다음과 같습니다.

• MIT License
  • MIT에서 만든 라이센스로, 모든 행동에 제약이 없으며, 저작권자는 소프트웨어와 관련한 책임에서 자유롭습니다.
  • 오픈소스 프로젝트시 이걸로 진행하면됨

• Apache License 2.0
  
  •  Apache 재단이 만든 라이센스로, 특허권 관련 내용이 포함되어 있습니다.
  • 오픈되어 있지만, Apache꺼다!! 라는 느낌이 있음. 제약이 있긴함
•  GNU General Public License v3.0
  •  가장 많이 알려져있으며, 의무사항(해당 라이센스가 적용된 소스코드 사용시 GPL 을 따라야 함)이 존재합니다.
  • 의무사항때문에 나중에 문제가 생길 수 있으니 오픈소스프로젝트 진행시 지양

 

 

Branch

*checkout가 두가지의 기능이 있어서 switch와 restore로 명령어가 나뉘어짐

• 분기점을 생성하여 독립적으로 코드를 변경할 수 있도록 도와주는 모델

 

Show available local branch

$ git branch

Show available remote branch

 $ git branch -r

Show available All branch

 $ git branch -a

Create branch

 $ git branch stem

Checkout branch

 $ git switch stem

Create & Checkout branch

 $ git swich -b new-stem

make changes inside readme.md

 $ git commit -a -m 'edit readme.md'
 $ git checkout master

merge branch

 $ git merge stem

delete branch

 $ git branch -D stem

push with specified remote branch

 $ git push origin stem

see the difference between two branches

 $ git diff master stem

 

브랜치 모델

• git flow
  • (hotfix) - master - (release) - develop - feature
  • 장점: 가장 많이 적용, 각 단계가 명확히 구분
  • 단점: 복잡
  • 가장 많이 사용되었었음
  • 용도가 명확히 구분되어있음
  • master, develop 두가지의 메인스트림 브랜치feature branch: 기능개발을 위함
  • release branch: develop에서 master로 넘어가기 위함
  • hotfix branch :master에서 긴급한 패치를 위함
  • 스프린트라는 주기를 통해서 일정기간동안 기능들을 모아 한번에 릴리즈하는 개발에 적합
  • 현재는 CI/CD가 발달하여 github flow, gitlab flow를 많이 사용하는 추세

• github flow
  
  • master(main) - feature
  • 장점: 브랜치 모델 단순화, master의 모든 커밋은 deployable
  • 단점: CI 의존성 높음. 누구 하나라도 실수하면 안됨 -> pull requeste로 방지

• gitlab flow
  • production - pre-production - master - feature
  • github flow단점보완, git/gitgub flow의 장점을 섞음
  • 장점: deploy, issue에 대한 대응이 가능하도록 보완
  • 단점: git flow와 반대(master-develop, production-master)

 

 

이 게시물은 카카오캠퍼스 라이브특강 최우영강사님의 강의 및 강의 자료를 참고하여 작성하였습니다.