Git은 버전 관리 시스템(VCS, Version Control System)의 한 종류이다.
다른 버전관리 시스템으로는 SVN이 있다. Git과 SVN의 차이가 궁금하다면, Quora의 이 질문(What is difference between SVN and Git?)에 대한 답변들을 살펴보길 권한다.
Git은 버전/브랜치 별로 프로젝트의 형상을 관리할 수 있기 때문에 1인개발에도 유용하며, 협업시엔 Merge 기능을 이용해 생산성을 올릴 수도 있다. 또한 코드 리뷰에 이용하기도 한다.
Git을 사용할 수 있는 GUI 기반의 응용 프로그램(SourceTree)들도 있지만, 필자는 CLI로만 정리했다.
형상관리의 핵심인 스테이징과 커밋이다.
어떤 기능을 구현했는지, 어떤 버그를 잡았는지를 커밋 메세지와 함께 커밋하면, 나중에 해당 커밋으로 복귀할 수도 있다. 타임 스탬라고 생각하면 좋다. 지금까지 한 작업을 스탬프로 찍으면 언제든 지금 찍은 스탬프로 돌아올 수 있다는 이야기이다.
RPG 게임을 하다가 어려운 스테이지를 앞두고 미리 게임을 저장하는 일과도 같다.
Git의 작업 흐름도와 각각 작업에 따른 명령어는 다음과 같다.
Local과 Remote는 각각 개발자가 개발과 형상관리를 하고있는 곳을 Local, 형상관리한 파일이 저장된 원격저장소가 Remote에 해당한다. 즉 컴퓨터로 개발을 하고 Github에 형상관리를 저장해둔다면, 컴퓨터가 Local에 해당하고, Github이 Remote에 해당한다는 이야기이다.
Local은 다시 3가지로 구분될 수 있는데, working directory와 staging area, local repo가 있다. 각각의 장소의 역할은 다음과 같다.
| where | role |
|---|---|
| working directory | 개발자가 작업을 하고 있는 프로젝트 디렉토리이다.git init 으로 버전관리되고 있는 로컬 작업환경이다. |
| staging area | 형상관리 될 파일들, 즉 커밋할 파일들이 머무르는 장소이다. 커밋을 위해 커밋할 파일들을 staging area에 올려두고 커밋 메세지와 함께 커밋을 하면, local repo로 이동한다. |
| local repo | 최종적으로 커밋이 보관되는 장소이다. Github, Gitlab같은 원격 저장소(Remote)에 push할 수 있다. |
| remote repo | Github, Gitlab과 같은 Git 호스팅 서비스에서 제공하는 원격 저장소에 해당한다. |
그럼 직접 파일을 생성하고, 커밋을 해보자.
일단 파일을 생성하고 명령어 git init 으로 디렉토리에 Git을 셋팅하였다.
여기서 file_01.java 파일을 커밋하기 위해서 스테이지에 올려보겠다.
git status 명령어로 보니 파일들이 서로 다르게 표시된걸 확인할 수 있다. 녹색으로 표시되는 파일이 스테이지에 올라간 파일이며, 이 파일은 커밋 대상이 된다.
만약 커밋하고 싶지 않은 파일이 staging area에 올라갔다면, git restore --staged <file> 로 working directory로 복귀시킬 수 있다. 아래 내용을 참고바란다.
이제 staging area에 있는 파일을 커밋하고 확인해보겠다.
만약 변경사항이 있는 모든 파일을 staging하고 싶다면,
git add -A명령어로 한번에 staging이 가능하다.
file_01.java 파일을 커밋하고 git status 를 확인해보니 file_01.java 파일이 사라진걸 확인할 수 있다. 커밋에 file_01.java 파일의 최신 변경사항이 반영되었기 때문에 Untracked files 목록에서 사라진 것이다.
Untracked files들은 아직 커밋을 만들지않아서 git에서 추적(tracking)하지 못하는 파일들이다.
만약 다시 file_01.java 파일을 수정한다면 modified 목록에 수정된 파일이 보여질 것이다.
Tracking 되고 있는 파일중에 변경사항이 발생했으니 새로 staging area에 올려서 커밋하라는 메세지이다.
다시 커밋을 하고, 커밋 목록만 따로 조회해보겠다. 명령어는 git log 를 사용한다.
작성자와 날짜, 시간, 커밋에 포함된 파일목록 그리고 커밋 ID가 출력된다.
위에서 작성된 스테이징 방식(git add file)이 파일 단위라면, 여기서 언급되는 스테이징 방식은 작업의 변경사항 단위로 스테이징하는 방법이다.
하나의 파일 안에서도 변경한 부분이 몇 가지가 될 수 있는데, 이 때 git add file 을 사용하면 파일이 통째로 스테이징된다. 그러나 git add -p 를 사용하면 변경사항 단위로만 커밋 할 수 있다. 더 편하고 더 분명하게 버전관리 할 수 있다고 생각한다.
$ git add -p이 때의 변경사항 단위를 Hunk라고 한다. hunk는 staging된 파일만 추적가능하다. 이번 변경사항에서 신규 생성된 파일이 있다면, 신규 생성된 파일은 hunk가 추적되지 않음을 주의하자.
test 폴더를 만들어서 실습을 해보았다.
생성한 파일(test.html)에 세 줄의 코드를 추가하고, 명령어 git add -p 를 입력하였다.
여기서 s 는 split을 의미한다. 세 줄을 한 꺼번에 스테이징하기 보다 더 세분화해서 스테이징하기 위해 split을 하는거다. split을 한 결과는 다음과 같다.
하나의 hunk가 3개의 hunk로 쪼개져서 각각 스테이징 할 수 있었다. 세 줄의 코드중 마지막 줄 코드만 스테이징 하지 않기로 했다.
다시 git add -p 을 입력해보니 아까 스테이징 하지 않은 한 줄의 코드만 스테이지 여부를 묻고, 나머지 코드는 스테이징 되었음을 확인할 수 있었다.
이처럼 git add -p 를 사용하면, 변경사항 단위로만 스테이징이 가능하다.
git add -p 에서 응답할 수 있는 명령어는 ? 을 입력하면 볼 수 있는데, 다음과 같다.
주로 쓰이는 명령어는 y, n, q 이다.
y : 해당 hunk를 스테이징한다.
n : 스테이징하지않고 건너뛴다.
q : add 과정을 종료한다.
staging area에서 working directory로 돌리는 방법에 관한 방법이다.
git add . 명령어로 작업한 파일 전체를 staging area에 올려두었는데, 이 중 커밋되면 안되는 파일을 발견했다. 이 땐 아래의 명령어를 통해 staging된 파일을 working directory로 복귀시킬 수 있다.
$ git restore --staged "file path"file_02.java 파일을 staging area에 올려두었다가 다시 untracking file로 바꾼 상태이다.
git add . 로 여러개의 파일이 올라갔는데, 모두 unstaing하고 싶다면?
$ git restore --staged *Source Tree 같은 GUI 기반의 프로그램을 이용하면, 쉽게 git log를 그래프로 확인할 수 있지만, 터미널에서 CLI로 작업을 할 땐 어떻게 git log를 볼 수 있을까?
먼저 git log를 한 줄로 보는 방법이다.
$ git log --all --oneline
이렇게 하면 시간순으로 커밋을 볼수는 있지만 브랜치간 구분이 되지 않아서 가독성이 좋지는 않다.
$ git log --all --oneline --graph --decorate
각 브랜치간 커밋을 구분하여 가독성있게 git log를 확인할 수 있게되었다.
$ git branch unit-Testunit-Test 라는 이름의 브랜치를 생성할 수 있다.
로컬 저장소의 모든 브랜치를 확인하고 싶다면,
$ git branch
원격 저장소 브랜치까지 모두 확인하고 싶다면,
$ git branch -a
$ git checkout master
$ git branch -D unit-Test$ git push origin --delete unit-Test원격 저장소에서 unit-Test 브랜치가 삭제된다.
출처 : 정광섭 - git 원격지 브랜치 삭제
만약 이름을 변경하길 원하는 브랜치가 선택되어 있다면,
$ git branch -m new-name현재 선택된 브랜치가 아닌 다른 브랜치의 이름을 변경하고자 한다면,
$ git branch -m old-name new-name
원격 저장소에서 적용하기
$ git push origin :old-name변경된 새 브랜치 원격 저장소에 적용하기
$ git push --set-upstream origin new-name
출처 : W3docs - How to Rename Git local and remote branches
중복된 내용의 커밋이 존재할 경우, 이를 하나의 커밋으로 합치면 깔끔하게 git log 를 볼 수 있다.
$ git rebase -i HEAD~~위의 명령어는 최신 노드 기준 2개의 커밋을 rebase하는 명령어이다. 만약 3개의 커밋을 정리하고자 한다면 아래와 같이 작성하면 된다.
$ git rebase -i HEAD~3아래 실습을 해보았다.
세 개의 커밋이 있는 깃 레포지토리를 만들어봤다.
$ git rebase -i HEAD~~명령어를 입력하면 다음과 같은 화면이 출력된다.
HEAD를 바라보는 기준으로 2개의 커밋이 출력되었는데 commit - B, commit -C 순으로 작성된 커밋들이다. commit -C 를 commit - B 로 합병할 생각이다. 이 때 commit -C 에 pick이라고 되어있는 부분을 squash라고 수정하고 입력모드를 나간다. :wq
그럼 합병되면서 새로 생성되는 커밋 메세지를 입력하는 창이 출력된다.
커밋메세지를 수정하고 나가서 커밋로그를 확인해보니 잘 합병되었음을 확인하였다.
커밋 순서를 바꾸는것도 rebase로 가능하다.
위의 실습 레포지토리에서 커밋 commit - D 를 생성했다.
이 상태에서 rebase를 시도했다.
$ git rebase HEAD~~
여기서 변경하고 싶은 커밋을 순서만 바꾸면 된다. 리눅스 명령어를 사용해서 쉽게 바꾸었다.
yy(한줄복사) 로 합병된 커밋(commit - B, commit -C)을 복사하고, commit - D 아래로 p(붙여넣기) 를 눌러서 붙여넣었다. 그리고 원래 위치가 변경되면서 사라질 커밋은 dd(한줄삭제) 를 입력해서 삭제했다.
git log를 확인해보니 순서가 제대로 변경되었음을 확인할 수 있다.
$ git rebase -i HEAD~~
rebase 명령어를 입력하고 화면이 출력되었을 때, 메세지를 수정하고자 하는 커밋의 앞에 edit으로 바꿔준다. 그리고 입력모드를 나간다 :wq
그럼 아래와 같은 화면이 출력된다.
위의 메세지대로 커밋 메세지를 작성하는 명령어를 입력한다.
$ git commit ---amend -m "new commit message"새로운 메세지로 커밋 메세지가 변경되었다.
$ git commit --amend$ git diff HEAD$ git diff HEAD HEAD^$ git diff origin/master origin/branch_02$ git stash현재 stage를 임시저장소에 저장
$ git stash list임시저장소에 저장한 stash 리스트 출력
$ git stash show 0stash 상세 조회하기. 인덱스를 리스트의 stash를 선택 조회가 가능하다.
$ git stash pop 0임시 저장한 stash를 다시 staging하기
현재 커밋 로그 상태이다. 여기서 8b2da2 로 시작하는 커밋으로 이동하려고 한다. 정확히는 이동이 아니라 HEAD가 바라보는 커밋을 02860e 에서 8b2da2로 변경하는 것이다.
HEAD가 바라보는 커밋을 바꾸고 싶을 땐(커밋 이동), checkout 명령어와 함께 바라보고 싶은 커밋주소 앞의 6자리를 입력하면 된다. (근데 5자리만 입력했는데도 잘 이동이 된다..?)
$ git checkout 8b2da
git log 를 확인해보니 잘 이동되었음을 확인하였다.
다시 돌아오고자 한다면 브랜치로 checkout 하여 최신 커밋으로 돌아올 수 있다.
$ git checkout [branch-]
test 브랜치가 바라보는 최신 커밋으로 잘 돌아왔다.
$ git push --force-with-lease일반적인 git push --force 와 달리 이 명령어는 overwrite하지 않고 원격저장소에 안전하게 커밋 히스토리를 적용한다고 한다.
Git 공식문서에서는 --force-with-lease 에 대해 다음과 같이 설명하고 있다.
--force-with-leasealone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have for them.
출처 : [https://git-scm.com/docs/git-push](
로컬 저장소가 바라보고 있는 원격 저장소의 url을 보는 방법은 다음의 명령어로 확인가능하다.
$ git remote -v그게 현재 로컬 저장소가 바라보는 원격 저장소의 url인데 이걸 바꾸려면 다음의 명령어로 바꿀 수 있다.
git remote set-url origin https://github.com/youngjinmo/youngjinmo.github.io.git저장소를 처음만들고, 원격 저장소에 지정할 때의 명령어는 아래와 같다. 아직 지정해둔 원격 저장소가 없을 때엔 remote와 origin 사이에 add를, 지정해둔 원격 저장소 주소를 바꾸고 싶을 땐 set-url을 붙이는 차이가 있다.
$ git remote add origin https://github.com/youngjinmo/youngjinmo.github.io.git그리고 변경사항을 푸쉬하면 제대로 이동되었음을 확인할 수 있다.
$ git push -u origin master$ git clone -b {branch-name} --single-branch {repository-url} 레포지토리의 브랜치 확인
커맨드라인에서 gh-pages 브랜치만 clone.
Fork는 다른 사람의 저장소를 내 저장소를 가져오는 기능이다. 정확히는 내가 Fork한 시점까지의 버전/커밋만 가져올 수 있다. 이후에 원래의 저장소, Upstream 저장소에 변경사항이 발생해도 내 저장소에 자동으로 반영되지는 않는다. 이 때엔 수동으로 Upstream 저장소의 변경사항을 동기화(fetch)하고 변경사항을 가져와야 한다. 자세한 방법은 여기를 참고바란다.
Git 호스팅 서비스(Github, Gitlab)는 원격 저장소이다. 이런 원격 저장소에서 내 컴퓨터로 즉 로컬로 가져오는게 Clone이고, 원격저장소 내에서 내 이름의 저장소로 가져오는 행위는 Fork이다. 이 부분을 헷갈리지 않을 필요가 있다.
Fork를 하면, Fork하는 시점의 커밋까지를 자신의 원격 저장소로 복제하게 된다. 위의 녹색 라인 기준으로 오른쪽 상태에 해당한다. Fork한 프로젝트를 작업하고자 한다면, Pull 해서 로컬에서 작업하면 된다.
그러나 이렇게 되면, 원래의 저장소(Upstream)에 변경사항이 발생했을 경우 이를 로컬에 적용하려면 어떻게 해야할까?
우선 현재 로컬 저장소가 어떤 저장소들을 가리키는지 확인하자.
$ git remote -v
여기서 origin 은 로컬과 직접적으로 연결되어 push하면 커밋들이 이동하는 저장소이다. upstream 은 이 저장소가 fork하기 전 원래의 저장소를 의미한다.
만약 upstream 저장소가 존재하지 않는다면, 이를 등록하면 된다.
$ git remote add upstream https://github.com/sarojaba/awesome-devblog.git정상적으로 등록되었다면, 이제 원격 저장소의 최신 변경사항을 불러오면 된다.
$ git fetch upstream
$ git merge upstream/masterfetch 는 현재 바라보고 있는 upstream 저장소에 최신 변경사항이 있는지 확인한다는 명령어이다.
이렇게하면 최신 변경사항을 가져올 수 있다.
만약 로컬 저장소의 브랜치명과 upstream 저장소의 브랜치명이 서로 다를때 문제가 발생할 수 있다. 예를들어, 로컬 저장소의 브랜치명은 master 인데, upstream 저장소의 브랜치명이 main 으로 업데이트 되었다면, 어떻게 해야할까?
로컬의 master 브랜치가 upstream 저장소의 main 브랜치임을 가리키면 된다.
$ git checkout -b master --track origin/main깃헙에서 PR이라는 단어를 자주봤을 것이다. PR은 Pull Request의 약어이다. 말 그대로 내가 작성한 커밋을 Pull 해달라고 요청하는 것이다. PR이 사용되는 경우는 아래의 경우에 해당된다.
프로젝트에 사용하는 공용 저장소를 Fork해서 자신의 저장소로 가져왔다. 여기에서 기능을 추가해서 커밋을 했는데 이게 프로젝트에 반영되려면 원격 저장소(Upstream)에 PR를 하는 것이다.
오픈소스에 기여(Contribution)하는 방법도 이와 같다. 오픈소스를 사용하다가 버그가 발견되었을 때, 해당 버그를 해결하기 위해 Fork한 저장소에서 버그를 해결한 코드를 작성후, PR을 하고, 원작자가 이를 받아들여서 오픈소스에 반영되면 내 이름이 컨트리뷰터에 오르게 된다.
PR하는 방법을 살펴보자.
Github에 접속하면 Pull Request가 활성화되어있는 걸 확인할 수 있다.
그 왼쪽의 메세지를 읽어보면, *'이 브랜치에 10개의 커밋이 [Upstream Owner:branch]를 바라보고 있다'*고 알려주고 있다. 이는 Upstream에 PR을 보낼 수 있는 10개의 커밋이 있다는 이야기이다.
Upstream 저장소의 어떤 브랜치에 내 커밋을 병합(merge)할 것인지, 또 내가 보낼 커밋은 어떤 브랜치의 커밋인지를 맞춘뒤 Create pull request 버튼을 클릭하면 Merge 커밋메세지를 작성할 수 있다. Upstream의 오너가 이를 수용해서 merge하면 내가 작성한 커밋이 한꺼번에 Upstream의 브랜치에 반영된다.
git으로 버전관리를 하다보면, 버전관리할 필요가 없는 불필요한 파일이 발생하기도 한다. MacOS에서는 ".DS_Store"라는 운영체제 관련된 파일이 생성되는데 이게 저장소로 push되면, 다른 운영체제의 contributor가 작업시에 conflict가 발생될 수 있다.
따라서 이런 파일들은 .gitignore 라는 파일로 버전관리목록에서 제외시켜야 한다.
vi에디터로 .gitignore 파일을 생성한다. 그리고 버전관리 하지않을 파일의 목록 또는 파일의 디렉토리명을 입력해두면, git status에서 확인되지 않는다.
.gitignore 에서 .DS_Store 파일들을 버전관리 목록에서 제외하라고 작성해두었다.
그리고 git 명령어 git status로 확인해보자.
더 이상 .DS_Store 파일이 보이지 않는 것을 확인할 수 있다.
이미 원격 저장소에 들어간 파일을 ignore해봐야 반영되지 않을 것이다. 이땐 다음의 절차대로 하면 원격 저장소로 넘어간 파일도 ignore할 수 있게된다.
ignore하고자 하는 파일을 삭제.- 새로운 커밋 생성
.gitignore에 파일명 또는 포맷을 작성해서 ignore.- 명령어
git status통해 확인
로컬에서 커맨드라인으로 git을 관리하기 위해서는 계정이 필요하다.
$ git config --global user.name "이름"
$ git config --global user.email "이메일"
$ git config --global user.password "패스워드"git config를 저장하는 가장 쉬운방법이지만, 보안으로는 가장 취약한 방식이다.
아래의 명령어를 입력하면, 현재의 쉘에 저장된 credential을 바로 확인할 수 있다.
$ git config --list
패스워드를 입력하지 않고 바로 확인할 수 있는 방법만큼 좋은 방식같지는 않다.
저장소별 config 설정을 다르게 할 수도 있다. 이땐 옵션명령어로 --global 대신 --local 을 사용하면 된다.
$ git config --local user.name "이름"
$ git config --local user.email "이메일"Github Credential이란 Github의 계정정보를 말한다.
저장소에 push/pull 하거나 private 저장소를 clone하기 위해서는 해당 저장소를 이용할 수 있는 권한이 필요한데 이 때 credential에 계정 정보를 저장해두면 저장소 이용시마다 로그인할 필요가 없다.
터미널 명령어는 다음과 같다.
$ git config credential.helper store
$ git push https://github.com/repo.git
$ Username for 'https://github.com' : your github email
$ Password for 'https://your github email' : your github password출처 : git-scm - git credential store
그러나 이 방식도 git config와 마찬가지로 안전하다고 볼 수는 없다. 보안상 추천하는 방식은 다음과 같다.
쉘에서 SSH 키를 생성한 후, 이를 Github에 저장해서 사용하려고 한다.
위키백과에 의하면, SSH(Secure Shell)는 네트워크 상의 다른 컴퓨터에 로그인하거나 Github과 같은 원격 시스템에 명령을 실행하고 다른 시스템으로 파일을 복사할 수 있는 프로토콜이라고 한다.
SSH는 암호화되어 통신하기 때문에 통신이 노출되더라도 안전하다고 한다.
먼저 쉘에서 SSH 키를 생성해보겠다.
터미널에서 아래 명령어를 입력한다.
$ ssh-keygen -t rsa -b 4096 -C "[email protected]"그럼 key pair가 생성된다.
> Generating public/private rsa key pair.이후에 프롬프트(Terminal)에 입력을 요구하는 메세지가 출력된다.
> Enter a file in which to save the key (/Users/you/.ssh/id_rsa): [Press enter]엔터를 입력하고,
> Enter passphrase (empty for no passphrase): [Type a passphrase]
> Enter same passphrase again: [Type passphrase again]기억할 수 있는 문장을 두번 입력한다.
그리고 터미널에 아래의 명령어를 입력하여 ssh-agent 를 실행한다.
$ eval "$(ssh-agent -s)"
> Agent pid 59566pid는 리눅스, 맥 등의 유닉스 관련 대부분의 OS 커널에서 사용하는 Process ID라고 한다. (출처)
그리고 시에라 버전 10.12.2 이상의 맥을 사용한다면, ~/.ssh/config 를 수정해주어야 한다.
Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_rsa그리고 SSH 키를 ssh-agent에 연결하고 기억할 수 있는 문장(passpharase)를 키체인에 저장한다.
ssh-agent는 리눅스 또는 유닉스 계열의 OS에서 로그인이 필요할 때 자동으로 config 를 도와준다고 한다.
$ ssh-add -K ~/.ssh/id_rsa이제 Github 설정에서 방금 생성한 SSH 키를 등록할 것이다.
생성한 키(~/.ssh/id_rsa.pub)를 복사한다.
$ pbcopy < ~/.ssh/id_rsa.pub그리고 Github 설정의 왼쪽 메뉴바에서 **[SSH and GPG key]**를 클릭한다.
[New SSH key] 를 클릭한다.
Title은 입력하고 싶은 이름을 입력해두고, Key에 아까 복사해뒀던 키를 붙여넣기해주면 된다.
출처
깃헙에서 오픈소스 레파지토리를 보면 항상 보던게 있다.
오픈소스에 해당하는 라이센스의 최소한의 기준을 정의하기 위해 OSD(Open Source Definition)를 정의해두고 이 정의에 따라 인증, 관리 및 촉진시키고 있다고 한다.
- GNU General Public License(GPL) 2.0
- GNU Lesser GPL(LGPL) 2.1
- Berkeley Software Distribution(BSD) License
- Apache license
- Mozilla Public License(MPL)
- MIT License
GPL은 현재 가장 많은 오픈소스 소프트웨어가 채택하고 있는 라이센스이다. 오픈소스 라이센스들 중에서 가장 많이 알려져 있고 의무사항들도 타 라이센스에 비해 엄격한 편이다.
- 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 GPL에 의해 배포된다는 사실 명시
- 소프트웨어를 수정하거나 새로운 소프트웨어를 병합(Dynamic linking 포함)시키는 경우 GPL에 의해 소스 코드 제공
- GPL 소프트웨어를 배포하는 경우, 소스 코드 그 자체를 함께 배포하거나 또는 소스코드를 제공받을 수 있는 방법에 대한 정보를 함께 제공
GPL 라이센스를 사용하기만 해도 소스코드를 공개해야 한다는 부담 때문에 단순한 라이브러리와 모듈로의 링크를 허용한 라이선스이다. 원래는 한정된 라이브러리에만 적용하려는 의도로 ‘Library GPL’이라는 이름을 붙였으나, 모든 라이브러리에 적용된다는 오해를 사 2.1 버전으로 ‘Lesser GPL’로 변경됐다.
- 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 LGPL에 의해 배포된다는 사실 명시
- LGPL Library의 일부를 수정하는 경우 수정한 Library를 LGPL에 의해 소스코드 공개
BSD 라이센스는 GPL/LGPL보다 덜 제한적이기 때문에 허용 범위가 넓다. 가장 큰 차이점은 소스코드를 공개하지 않아도 된다는 점이다.
- 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시
- 수정 프로그램에 대한 소스 코드의 공개를 요구하지 않기 때문에 상용 소프트웨어에 무제한 사용가능
아파치 소프트웨어 재단에서 자체적으로 만든 소프트웨어에 대한 라이센스 규정이다.
아파치 라이센스는 아파치 재단(ASF: Apache Software Foundation)의 모든 소프트웨어에 적용되며 BSD 라이센스와 비슷하여 소스코드 공개 등의 의무가 발생하지 않는다. 다만 “Apache”라는 이름에 대한 상표권을 침해하지 않아야 한다는 조항이 명시적으로 들어가 있고, 특허권에 관한 내용이 포함되어 BSD 라이센스보다는 좀더 법적으로 완결된 내용을 담고 있다. 특히 GPL 2.0으로 배포되는 코드와 결합되는 것이 어렵다는 문제가 었었는데, GPL 3.0에서는 이 문제를 해결하여 아파치 라이센스로 배포되는 코드가 GPL 3.0으로 배포되는 코드와 결합하는 것이 가능해졌다.
MPL은 Netscape 브라우저의 소스코드를 공개하기 위해 개발된 라이센스이다. MPL에서는 링크 등의 여부에 상관없이 원래의 소스코드가 아닌 새로운 파일에 작성된 소스코드에 대해서는 공개의 의무가 발생하지 않는다.
- 소프트웨어를 배포하는 경우 저작권 표시, 보증책임이 없다는 표시 및 MPL에 의해 배포된다는 사실을 명시
- MPL 코드를 수정한 부분은 다시 MPL에 의해 배포
- MPL 코드와 다른 코드를 결합하여 프로그램을 만들 경우 MPL 코드를 제외한 결합 프로그램에 대한 소스코드는 공개할 필요가 없음
- 소스코드를 적절한 형태로 제공하는 경우, 실행파일에 대한 라이센스는 MPL이 아닌 다른 것으로 선택가능
- 특허기술이 구현된 프로그램의 경우 관련 사실을 **‘LEGAL’**파일에 기록하여 배포
MIT 라이센스는 미국 매사추세츠공과대학교(MIT)에서 해당 대학 소프트웨어 공학도들을 돕기 위해 개발한 라이센스이다. 라이센스와 저작권 관련 명시만 지켜주면 되는 라이센스이다.
- 이 소프트웨어를 누구라도 무상으로 제한없이 취급해도 좋다.
- 저자 또는 저작권자는 소프트웨어에 관해서 아무런 책임을 지지 않는다.
$ vim ~/.gitmessage.txtvim 에디터가 열리면 여기서 템플릿을 만들면 된다. 필자는 이렇게 작성했다.
# 제목은 최대 50글자까지 아래에 작성: ex) <feat>: Add OAuth2
# 본문은 아래에 작성
# 꼬릿말은 아래에 작성: ex) Github issue #23
# --- COMMIT END ---
# <타입> 리스트
# feat : 기능 (새로운 기능)
# fix : 버그 (버그 수정)
# refactor: 리팩토링
# style : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
# docs : 문서 (문서 추가, 수정, 삭제)
# test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# chore : 기타 변경사항 (빌드 스크립트 수정 등)
# ------------------
# 제목 첫 글자를 대문자로
# 제목은 명령문으로
# 제목 끝에 마침표(.) 금지
# 제목과 본문을 한 줄 띄워 분리하기
# 본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
# 본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# ------------------다시 한 번 언급하지만 이 템플릿이 열리며 커밋 메세지를 작성하기 때문에 커밋 메세지 작성에 대한 규칙을 여기에 명시하면 된다. 내가 아닌 다른 사람들이 보고 쉽게 작성할 수 있도록 최대한 명료하게 작성하는게 중요하다.
$ git config --global core.editor vim다른 에디터(emacs)를 사용하는 사람이라면, 위 커맨드 명령어중 vim을 다른 명령어로 교체하면 된다.
$ git config --global commit.template ~/.gitmessage.txt이제 커밋(git commit)을 명령하면, gitmessage 템플릿에서 작성할 수 있게 된다.
윈도우에서 git bash를 이용하다가 발견한 현상이다. 우연히 블로깅을 하다가 이걸 해결하는 방법을 찾게되어 정리한다.
공식문서를 보면, 이런 현상이 발생하는 이유는 파일명에 unusual한 문자열이 있을 경우, 이를 "/"와 함께 해당 문자열을 닫아버리기 때문에 발생하는 현상이라고 한다. uncasual하다는건 해당값의 bytes가 0x80보다 클 경우라고 하는데, UTF-8이 이 경우에 해당하는듯하다.
아무튼 이런 기능을 담당하는게 core.quotepath 인데 이걸 비활성화하면 한글을 다시 출력할 수 있다.
$ git config --global core.quotepath false