앞에서 커맨드를 사용해 저장소 생성, 커밋, 푸쉬하는 법을 다뤘습니다. 여기서는 브랜치 생성, 머지하는 방법을 설명합니다.

브랜치 확인

명령어를 통해 현재 어떤 브랜치가 있고 활성화된 브랜치가 무엇인지 확인할 수 있습니다.

$ git branch=

* master
(END)


현재 master 브랜치만 존재합니다. *가 붙어있는 브랜치가 현재 활성화된 브랜치라고 볼 수 있습니다.


옵션 -v를 추가하면 브랜치마다 마지막 커밋 메시지를 확인할 수 있습니다.

$ git branch -v

* master 48fc51f [ahead 1] test2
(END)


원격 저장소의 브랜치를 확인하려면 -r 옵션을 추가하면 됩니다.

$ git branch -r

  origin/HEAD -> origin/master
  origin/master
(END)


또한 현재 활성화된 브랜치를 기준으로 머지가 된 브랜치인지 아닌지 확인할 수 있습니다. 이 예를 들기 위해, test라는 브랜치에서 별도의 작업 후 커밋까지 완료를 했습니다.

$ git branch --merged

* master
(END)


test 브랜치에서의 작업 내용이 현재 master 브랜치에 머지가 되지 않아서 리스트에 나오지 않습니다. 위 명령어와 반대로 머지가 되지 않은 리스트 조회는 아래와 같이 요청합니다.

 $ git branch --no-merged

 test
(END)


위 test 브랜치는 머지가 되지 않은 목록으로 조회가 가능합니다.

브랜치 삭제

현재 활성화된 브랜치를 제외하고 삭제를 진행할 수 있습니다.

$ git branch

* master
  test
  test1
(END)

$ git branch -d test1

Deleted branch test1 (was 48fc51f).

$ git branch

* master
  test
(END)


test1은 현재 활성화된 브랜치와 코드가 동일하므로 삭제가 되지만 test 브랜치는 master브랜치와 머지가 되지 않아 해당 명령어로 삭제를 진행하면 에러 메시지를 출력합니다.

$ git branch -d test

error: The branch 'test' is not fully merged.
If you are sure you want to delete it, run 'git branch -D test'.


위 설명처럼 강제로 삭제하려면 -D 옵션을 사용해야 합니다.

$ git branch -D test

Deleted branch test (was 3d1be1a).

브랜치 생성

브랜치 생성 방법은 2가지가 있습니다.


브랜치를 생성한 다음, 생성한 브랜치로 이동하는 방법은 아래와 같습니다.

$ git branch test
$ git checkout test

Switched to branch 'test'


checkout 의 옵션인 -b를 사용해 생성 후, 바로 이동하도록 할 수 있습니다.

$ git checkout -b test1

Switched to a new branch 'test1'

브랜치 머지하기

git merge

머지란 다른 브랜치의 변경점을 현재 활성화된 브랜치에 합치는 의미입니다. 만약 활성화된 브랜치에 다른 브랜치를 머지하고 싶으면 아래와 같이 진행합니다.

$ git merge test

Updating de1f0ad..be3a368
Fast-forward
 test.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


만약 머지를 하기 전, 변경사항을 확인하고 싶으면 아래와 같이 진행합니다.

$ git merge master test

diff --git a/test.txt b/test.txt
index 7d3340a..4439738 100644
--- a/test.txt
+++ b/test.txt
@@ -1,2 +1 @@
 머지 테ㅡ트
-test2에서 test1을 <S-F6마스터에서:
(END)


master 브랜치에서 test 브랜치를 머지하면 test2에서 test1을 <S-F6마스터에서:  문장이 제거된다는 의미입니다.


머지가 완료되면 원격 저장소에 아래와 같이 반영합니다.

$ git push origin master

Counting objects: 12, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (12/12), 1.02 KiB | 523.00 KiB/s, done.
Total 12 (delta 0), reused 0 (delta 0)
To https://github.com/brownbears1/test.git
   6acb1a3..3262bf7  master -> master

git rebase

rebase를 사용하여 두 브랜치를 합칠 수 있습니다. rebase는 merge와 다르게 한 줄로만 커밋 메시지를 출력할 수 있습니다. 또한 master 브랜치에 test1 브랜치를 합친다 하면 아래와 같은 순서로 진행해야 합니다. 

$ git checkout test1
$ git rebase master

First, rewinding head to replay your work on top of it...
Applying: rebase 테스트

$ git checkout master
$ git rebase test1

First, rewinding head to replay your work on top of it...
Fast-forwarded master to test1.


rebase는 말 그대로 base 브랜치를 재구축하는 형태입니다. 위에서 test 브랜치를 활성화하고 rebase master를 진행하면 'master 브랜치를 바탕으로 현재 브랜치를 재구축' 이라는 의미입니다. 


merge와 rebase의 차이점

$ git log --graph


위 명령으로 브랜치의 커밋이나 머지를 그래프로 확인할 수 있습니다. 

아래는 merge 후 출력한 이미지 입니다.

master에서 test브랜치가 생성된 후, 'meerge test'라는 커밋 메시지로 커밋이 되었습니다. 이후 master 브랜치로 머지가 된 것을 확인할 수 있습니다. 여기서 보다시피 브랜치의 파생된 내역을 전부 확인할 수 있습니다.


반면 rebase를 진행하면 아래와 같이 보입니다.


rebase를 진행하면 브랜치의 base를 재구축하여 하나로 합치므로 브랜치의 파생내역을 볼 수 없습니다. 

위는 test1 브랜치에서 master 브랜치로 rebase한 다음, master에서 머지를 한 결과입니다. test1 브랜치에서 rebase를 한 시점에서 test1 브랜치가 master의 최신 커밋을 기반으로 재구축했기 때문에 위와 같은 순서를 보여줍니다. 이후, master 브랜치에서 test1브랜치를 merge 명령어로 합친다 해도, test1 브랜치의 base가 동일하기 때문에 1개의 라인으로 커밋 메시지를 확인할 수 있습니다.

외부 저장소를 fork를 하고 내용을 수정한 다음, 해당 저장소의 master에게 내가 변경한 사항을 확인하고 머지해 주세요 라는 의미로 pull request를 요청할 수 있습니다. 또한 원본 저장소에서 변경된 사항이 있으면 fork를 받은 내 저장소에는 반영이 되지 않으므로 동기화를 시켜줘야 합니다.

외부 저장소 fork하기


fork 할 저장소에 들어간 다음, star 버튼 옆에 있는 fork 버튼을 누릅니다.


organization이 여러개일 경우, 아래와 같이 팝업이 나오는데 fork할 위치를 지정해 줍니다.


fork에 성공하면 아래와 같이 계정에 새로운 저장소가 생성됩니다.


fork를 진행한 다음, 로컬에 해당 저장소의 파일을 내려받습니다.

$ git clone https://github.com/brownbears1/flit.git


Cloning into 'flit'...
remote: Enumerating objects: 67, done.
remote: Counting objects: 100% (67/67), done.
remote: Compressing objects: 100% (45/45), done.
remote: Total 3408 (delta 34), reused 46 (delta 22), pack-reused 3341
Receiving objects: 100% (3408/3408), 702.39 KiB | 953.00 KiB/s, done.
Resolving deltas: 100% (2290/2290), done.


pull request

pull request를 요청하기 전에 아래와 같이 작업을 진행해야 합니다.


위와 같이 fork 저장소를 clone 했다면 origin 이라는 이름에 fork 저장소가 지정되어 있습니다. 원본 저장소의 주소도 저장해야 하기 때문에 아래와 같이 명령어를 입력한 다음 확인합니다.

$ git remote -v
origin	https://github.com/brownbears1/flit.git (fetch)
origin	https://github.com/brownbears1/flit.git (push)


$ git remote add origin-flit https://github.com/takluyver/flit.git
$ git remote -v
origin	https://github.com/brownbears1/flit.git (fetch)
origin	https://github.com/brownbears1/flit.git (push)
origin-flit	https://github.com/takluyver/flit.git (fetch)
origin-flit	https://github.com/takluyver/flit.git (push)


파일 생성/변경이 전부 끝났다면 이제 fork 저장소에 push를 진행합니다.

$ git add .
$ git commit -m 'test'
$ git push origin master


push가 완료되었다면 이제 본인의 fork 저장소 페이지에 들어간 후, code 탭 옆의 Pull Request를 누른 다음 New Pull Request 버튼을 클릭합니다.



누르면 내가 push한 내용을 확인할 수 있고 원본 저장소의 어느 브랜치로 머지할지, 내 fork 저장소의 어느 브랜치로 pull request를 요청할지 고를 수 있습니다.


완료되었으면 pull request의 내용을 작성해야 하기 때문에 Create pull request 버튼을 클릭합니다.


제목과 내용을 작성한 후, Create pull request 버튼을 누르면 원본 저장소에 pull request 요청이 완료됩니다.

fork 저장소 동기화

위 순서대로 진행했으면 원 저장소의 주소가 입력되어 있지만 만약 아닐 시, 아래 명령어로 추가해 줍니다.

$ git remote add origin-flit https://github.com/takluyver/flit.git
$ git remote -v
origin	https://github.com/brownbears1/flit.git (fetch)
origin	https://github.com/brownbears1/flit.git (push)
origin-flit	https://github.com/takluyver/flit.git (fetch)
origin-flit	https://github.com/takluyver/flit.git (push)


다음 외부 저장소의 최신 내용을 가져옵니다.

$ git fetch origin-flit


다음 merge를 할 브랜치로 변경한 다음, 위에서 가져온 최신 내용을 merge 해줍니다.

$ git checkout master
$ git merge origin-flit/master


위 작업이 끝났으면 내 fork 저장소에도 반영을 해줍니다.

$ git push origin master


지금까지 gitlab이나 github을 사용할 때, 커맨드를 쓰지 않고 source tree에서 제공하는 GUI로 처리했습니다. GUI가 편리하긴 하지만, 프로젝트의 크기가 커지고 브랜치가 많아지는 경우 살짝 느려지는 경향이 있습니다. 이를 보완하고 git 커맨드에 친숙해지고자 커맨드를 사용하는 방법을 설명합니다.

git 저장소 생성

기존 폴더를 git 저장소로 추가

$ git init


Initialized empty Git repository in /.../test_git/.git/


test_git이라는 폴더를 저장소로 git 저장소로 추가한 방법입니다. 해당 폴더에 들어간 후, $ls -la | grep .git을 하면 .git 파일이 추가된 것을 확인할 수 있습니다. 로컬에서 .git을 추가한 것이므로 파일을 추가, 커밋, 푸쉬까지 이뤄져야 서버에도 반영이 됩니다. 해당 내용은 아래에서 천천히 설명합니다.

서버에 있는 저장소를 clone

gitlab이나 github에 있는 저장소를 로컬에 추가하고 싶을 때 사용합니다.

$ git clone https://github.com/brownbears1/test.git


Cloning into 'test'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.


test라는 프로젝트를 로컬에 내려받습니다. 이 때, 프로젝트명인 test라는 폴더에 생성이 됩니다. 만약 폴더명을 임의로 추가하고 싶으면 아래와 같이 지정하면 됩니다.

$ git clone https://github.com/brownbears1/test.git custom_test

파일 추가/수정 후 저장

위 test 프로젝트를 내려받았다면 자동으로 checkout이 된 상태입니다. 여기서 파일을 추가하고 수정한 다음, 해당 서버에 올리는 동작을 설명합니다.

tracked/untracked 이해하기

git에서 모든 파일은 tracked 와 untracked 상태로 나눌 수 있습니다.

tracked 상태는 스냅샷에 포함된 파일이고 unmodified(변경된 사항 없음), modified(변경됨), staged(커밋으로 저장소에 기록) 상태로 또 나눌 수 있습니다.

이외의 파일들은 untracked 상태이며 해당 상태의 파일들은 스냅샷에 포함된 것이 아니고 stage 대상도 아닙니다.

여기서 스냅샷의 의미는 git 저장소에 해당 파일이 있는지의 유무입니다. 스냅샷에 포함된 파일이라 하면, git 저장소에 존재하는 파일입니다.

unmodified 상태면 변경된 사항이 없는 상태이고

modified 상태면 git에 존재하는 파일의 내용을 수정한 상태이고 (이 상태는 배포 준비가 되지 않음)

staging은 modified의 상태에서 배포를 하겠다 라고 stage에 추가한 상태입니다. (배포시, 서버에 적용)

파일의 추가/수정 추적하기

프로젝트 내에 README.md 파일이 있어서 해당 내용을 수정한다고 가정합니다. 이후, 파일을 추적하기 전에 상태값을 확인하도록 합니다.

$ git status


On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")


여기서 git status는 변경/추가된 파일들을 보여줍니다. 위 상태는 README.md 파일에 변경이 있지만 아직 stage에 올라가지 않은 상태입니다. stage에 올리도록 아래와 같이 add를 한 후, 다시 status로 확인합니다.

$ git add README.md
$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   README.md


Changes to be committed 문구와 같이 stage 상태로 올라간 것을 확인할 수 있습니다.

이번에는 새로운 파일인 test.txt를 만들고 위와 같이 똑같은 절차를 진행합니다.

$ git status


On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	test.txt


$ git add test.txt
$ git status


On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   README.md
	new file:   test.txt


만약 위 stage 상태를 만든 다음, test.txt를 수정하게 된다면 파일의 상태가 unstage 상태로 됩니다. 이때, 수정한 내용은 커밋에 반영이 안되므로 다시 git add를 해야 합니다.


만약 생성/변경한 모든 파일을 stage로 추가하고 싶으면 아래와 같이 .을 사용합니다.

$ git add .

변경사항 커밋하기

위에서 설명한 것과 같이 stage 상태인 내용들을 커밋하도록 합니다.

$ git commit -m '커밋 테스트'

[master 457f83a] 커밋 테스트
 2 files changed, 2 insertions(+)
 create mode 100644 test.txt


여기서 커밋은 변경사항을 현재 내 컴퓨터에 저장하는 것이고 원격 저장소에는 반영이 되지 않은 상태입니다. -m '커밋 테스트' 에는 커밋 메시지를 작성하도록 합니다.


만약 git add 이후 stage 상태인 파일을 또 수정하게 된다면 다시 add를 해줘야 합니다. 이러한 번거로움을 덜고자 아래와 같이 사용하여 tracked 상태의 파일들이 변경사항이 있을 때, 자동으로 stage 상태로 추가하고 커밋하도록 할 수 있습니다.

$ git commit -am '커밋 테스트'

stage된 파일 제거하기

commit까지 이룬 상황에서 부득이하게 서버에 반영을 하지 않고자 하면 해당 파일을 제거해야 합니다. 

$ git rm test.txt


$ ll
README.md


위 명령어만 입력하면 stage 상태에서 제거되는 것 뿐만 아니라 실제 파일도 지워지게 됩니다. 아래 옵션을 사용하여 파일은 그대로 두되, git이 추적만 하지 않도록 진행할 수 있습니다.

$ git rm --cached README.md


rm 'README.md'


$ git status


On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	deleted:    README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	README.md

커밋된 내용 서버에 반영하기

커밋된 내용을 push 명령어를 사용해 원격 저장소에 반영할 수 있습니다. 

$ push -u origin master


Counting objects: 3, done.
Writing objects: 100% (3/3), 265 bytes | 265.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/brownbears1/test.git
   e4c4c0f..6acb1a3  master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.


여기서 origin은 원격 저장소의 이름이고 master는 브랜치 이름입니다. clone을 하면 보통 원격 저장소의 이름이 origin으로 지정됩니다. -u 옵션은 원격 저장소에서 업데이트를 받은 다음, push를 하는 의미입니다. 

이 옵션을 사용하는 이유는 해당 프로젝트를 복제한 사람들이 여러 명 있을 때, 다른 사람이 먼저 push를 하면 그 다음 사람들은 push를 할 수 없기 때문에 -u 옵션을 사용하여 최신 내용을 내려받아 머지한 다음, push를 해야 합니다.

이러한 이유 때문에 -u를 사용하지만 push를 하기 전, 프로젝트의 최신 내용을 먼저 pull 받은 다음 진행하는 것이 좋습니다.


만약 master에 반영하는 것이 아닌, 다른 브랜치에 반영을 하려면 master 대신 다른 브랜치의 이름을 지정하면 됩니다.


여기까지는 기존에 존재하는 원격 저장소를 복제한 다음 진행한 방법이고 새로운 폴더를 git 저장소로 추가한 경우 아래와 같이 원격 저장소의 주소를 추가해야 push가 가능합니다.

$ git remote add origin (원격 저장소 주소)

내용 되돌리기

모든 단계에서 생성/변경 한 파일을 되돌릴 수 있습니다. 여기서 주의할 점은 한 번 되돌린 내용은 다시 복구할 수가 없습니다.

commit 되돌리기

이미 커밋이 된 상태에서 커밋 메세지를 변경하거나, 다른 파일도 추가하여 커밋을 하고 싶을 때 사용할 수 있습니다.

$ git commit --amend -m '메시지'


만약 커밋을 한 다음, 다른 파일을 생성/추가가 안된 상태에서 위 명령어를 입력한다면 커밋 메시지만 변경한다는 의미입니다. 

unstage로 되돌리기

git add . 으로 모든 파일이 stage 상태가 되었는데 특정 파일을 unstage로 바꾼다고 할 때, 아래와 같이 사용할 수 있습니다.

$ git status


On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   README.md
	modified:   test.txt


$ git reset HEAD test.txt

Unstaged changes after reset:
M	test.txt


$ git status


On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   README.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   test.txt

modified 상태 파일 원복하기

기존에 존재하는 파일을 수정했다가 최근 원격 저장소에서 내려 받은 파일로 원복하는 방법은 아래와 같습니다.

git checkout -- README.md


이 방법으로 초기 파일 상태로 돌릴 수 있지만, 수정한 파일 위에 덮어쓰이는 방법 때문에 수정한 이력이 날라가 다시 복원을 할 수 없습니다.

원격 저장소에서 최신 내용 내려받기

만약 누군가가 master에 내용을 변경해서 푸쉬를 했다면, 현재 내 로컬 저장소의 master와 내용이 다릅니다. 이를 맞춰주기 위해 원격 저장소의 브랜치를 내려 받아 로컬 저장소에 합칩니다.

$ git pull


pull 명령을 사용하면 원격 저장소의 변경 내용이 로컬에 받아지고(fetch), 이를 합칩니다. (merge)

충돌 관리하기

충돌은 같은 파일을 여러 사람이 수정한 다음, 한 명이 push하고 다음 사람이 push할 때 일어날 수 있거나 pull을 받을 때 발생할 수도 있습니다.


만약 충돌이 났다면 아래와 같은 메시지를 확인할 수 있습니다.

First, rewinding head to replay your work on top of it... 
Applying: 더 보기 버튼 추가 
Using index info to reconstruct a base tree... 
M index.html Falling back to patching base and 3-way merge... 
Auto-merging index.html 
CONFLICT (content): Merge conflict in index.html 
Failed to merge in the changes. 
Patch failed at 0001 더 보기 버튼 추가 
The copy of the patch that failed is found in: 
  /path/to/.git/rebase-apply/patch 

When you have resolved this problem, run "git rebase --continue". 
If you prefer to skip this patch, run "git rebase --skip" instead. 
To check out the original branch and stop rebasing, run "git rebase --abort".


여기서 핵심은 아래 3줄입니다. 충돌 문제를 해결했으면 git rebase --continue , 해당 파일을 건너뛰려면 git rebase --skip ,  중단하려면 git rebase --abort 의 명령어를 용도에 맞게 사용하면 됩니다.


충돌한 파일을 열어보면 아래와 같이 구성되어 있습니다.

<<<<<<< HEAD
  <div>
  <p> 내가 수정한 내용 </p>  
  </div>
=======
  <div>
  <p> 현재 원격 저장소에 누군가 올린 내용 </p>  
  </div>
>>>>>>>


<<<< HEAD 부터 ===== 까지가 내가 수정한 내용이고 ==== 부터 >>>>까지 누군가가 수정한 내용입니다. 이 부분은 사용자가 잘 판단하여 아래와 같이 정상적인 파일로 만들어 줍니다.

<div>
  <p> 내가 수정한 내용 </p>
</div>


충돌 해결을 했으면 서버에 반영해야 하므로 아래와 같이 명령을 진행합니다.

$ git add index.html
$ git rebase --continue


시작하기 전에 hipchat, jenkins 계정은 모두 있다고 가정하고 설명합니다.

Hipchat

먼저 방을 생성한 다음, ... 버튼을 눌러 Integrations를 누른 후 Install new integrations를 선택합니다.



다음 Build your own integration 버튼을 클릭합니다.



다음 적당한 별칭 (bot의 이름)을 정해줍니다. 여기선 Deployment Bot이라 생성했습니다. (아래 스크린샷과 다름..)



Create버튼을 누르면 아래와 같은 화면과 


Send messages to this room by posting to this URL의 값이 있는데 여기서 room/252352 와 같이 room 번호와 auth_token=Hcr8hO8Hihoph8P 와 같은 api tocken을 따로 저장해둡니다. (jenkins에 등록할 때 필요함)


Jenkins



Jenkins > Credentials > System > Add Credentials을 눌러 아래와 같은 화면에서 Secret text를 선택한 후, Scope에 아까 적어놓은 api tocken을 붙여 넣습니다. id와 description은 jenkins에서 확인하는 용도로 아무 이름이나 지으면 됩니다.



다음 젠킨스 잡을 생성한 다음 '빌드 후 조치' 탭에서 HipChat notifications를 선택해 활성화 시킵니다.



마지막으로 Credentials부분에 아까 설정한 Credentials을 선택하고 미리 저장해놓은 프로젝트 방번호를 입력합니다.  다음 아래와 같이 언제 HipChat notifications을 발생할 지를 선택해주면 끝입니다.

'저장소' 카테고리의 다른 글

Jenkins - Hipchat 연동  (0) 2017.10.16
SourceTree 설치방법 및 용어  (0) 2016.07.08

http://blog.appkr.kr/learn-n-think/comparing-workflows/

README.md 파일은 git, github 등과 같이 저장소에서 많이 본 파일입니다. 해당 파일은 소스코드에 앞서 어떠한 목적으로 개발이 되었는지, 코드의 개요, 구조도 등을 처음 사람들에게 노출함으로써 해당 프로젝트에 대해 설명을 합니다.

여기서는 여러형태의 리드미 파일을 전부 다루는 것이 아닌 현재 사용중인 gitlab의 README.md파일을 위주로 필요성 및 문법을 설명하도록 하겠습니다.

리드미(readme)란?


리드미 (README, readme, read me) 파일은 디렉토리나 압축 파일에 포함된 기타 파일에 대한 정보를 가지고 있으며, 일반적으로 소트프웨어와 함께 배포됩니다. 또한 현재 git과 같은 저장소에서도 해당 파일을 default로 생성하여 해당 저장소에 대한 설명을 기입하도록 하고 있습니다.

리드미의 파일 형태는 README.TXT, README.md, README.1ST, README.DOC READ.ME 또는 간단히 README 등 많은 파일 명과 확장자 형태를 가지고 있습니다.


리드미 (README의 다양한 형태를 여기서는 '리드미'로 부르겠습니다.)는 다음 중 하나 이상의 정보를 포함합니다.

  • 컴퓨터 구성 안내
  • 설치 안내
  • 사용법
  • 파일 메니페스트 (파일 목록 포함)
  • 저작권 및 사용권 정보
  • 배포자 및 프로그래머의 연락처 정보
  • 알려진 버그
  • 트러블슈팅
  • 크레딧
  • 체인지로그


위에 나열한 목록 이외의 정보를 포함할 수 있습니다. 또한 오픈소스 배포판을 일반적으로 아래와 같은 표준 집합의 리드미 파일들을 포함합니다.


README일반 정보
AUTHORS제작 정보
THANKS도와주신 분들에 대한 정보
ChangeLog프로그래머들이 참고 할 수 있는 자세한 체인지로그
NEWS사용자들이 참고할 수 있는 기본적인 체인지로그
INSTALL설치 안내
COPYING/LICENSE저작권 및 사용권 정보
BUGS알려진 버그 및 새로운 버그 보고 방법 안내

리드미 파일로 해당 프로젝트의 버젼, 이전버젼과 변경된 사항들, 파일 목록, 시스템 구조도 등을 작성하여 사용자들이 특이 사항들을 바로 확인 할 수 있도록 합니다.

리드미(readme)작성법


readme작성은 사실 사용자 마음대로 작성해도 되지만 Markdown 문법에 맞게 작성하면 html과 같이 더 멋지게 꾸밀 수 있습니다.

마크다운 소개 

마크다운(Markdown)은 일종의 마크업 언어로 텍스트에 태그를 이용해서 글자를 굵게 하거나, 이미지를 삽입하거나 하는 일이 가능합니다. 엔하위키에 글을 쓸 때 위키 언어를 이용해서 글을 써야하는데, 마크다운 언어는 그 위키 언어와 상당히 유사하다고 할 수 있습니다. 하지만 마크다운은 위키문법보다 훨씬 더 간단하므로 익히는데 그리 긴 시간이 필요하지 않다는 장점을 가지고 있습니다.

요즘 마크다운은 아주 여러 곳에서 사용되고 있습니다. 이제 워드프레스에서는 기본적으로 마크다운을 지원하기 시작했고, Tumblr나 Ghost와 같은 블로그 플랫폼에서도 마크다운 언어를 기본적으로 지원하고 있습니다. 그리고 심지어는 그누보드나 XE에도 마크다운을 쓸 수 있는 플러그인이 있어서 그 플러그인을 설치하면 그누보드나 XE에서 글을 쓸 때, 마크다운을 이용하는 것이 가능합니다.

마크다운의 장단점

장점

  • 읽기 쉽다.
    마크다운은 다른 마크업 언어에 비해 훨씬 알아보기 쉽습니다. 제목은 앞에 #을 붙여주면 되고, 글자를 강조하려면 글자 주위를 **으로 감싸주면 됩니다. HTML로 글을 쓸 때는, 그 글이 실제로 브라우저에 어떻게 보여질지 상상하는 것이 꽤 어려운 일이었다면 마크다운으로 쓴 텍스트는, 텍스트만으로 그 글이 브라우저에서 어떻게 보여질지 쉽게 상상할 수 있습니다.
  • 익히기 쉽다
    마크다운은 상당히 간단합니다. John Gruber가 처음에 마크다운을 만들었을 때, 사람들이 가장 많이 사용하는 기능만을 마크다운으로 쓰고, 복잡한 것은 HTML로 쓰도록 디자인했기 때문입니다. 그래서 비록 몇가지 제한이 있기는 하지만 마크다운으로 글을 쓸 때, 중간에 HTML을 그대로 써도 상관 없습니다.
  • 모바일 친화적이다
    요즘 모바일을 통해서 글을 쓰고 올리는 경우가 상당히 많아졌습니다. 그런데, 모바일로 서식이 들어간 글을 쓰는 것은 상당히 불편하다. 특히 모바일에서는 에디터가 제대로 작동하지 않는 경우도 있고, 작동하더라도 작은 화면때문에 에디터를 통해서 글을 작성하는 것이 상당히 불편한 경우가 많습니다. 하지만 마크다운을 이용해서 글을 쓰면 간단한 태그만으로 쉽게 서식을 넣을 수 있어서, 위지윅 에디터를 사용하는 것보다는 훨씬 편리합니다.

단점

  • 문법이 너무 단순하다
    문법이 너무 단순해서 그 기능을 벗어나려고 할 때는 결국 HTML을 써야하는 경우가 생깁니다. 예를 들어, 마크다운에는 이미지를 정렬하는 문법이 없습니다. 따라서 이미지를 정렬하려면 HTML의 img 태그를 써야합니다. 또한 태그에 클래스 지정등이 불가능하기 때문에, 클래스나 id를 지정하려면 역시 HTML을 써야합니다.
  • 확장 문법이 많다
    이것은 첫 번째 단점 때문에 발생한 문제라고 볼 수 있습니다. 문법이 너무 단순하기 때문에 그 불편함을 해소하기 위해서 여러가지 확장 문법들이 생기기 시작했고, 그런 파편화 때문에 한 곳에서 잘 작동하는 마크다운 문서가 다른 곳에서는 잘 작동하지 않는 현상이 생기기도 합니다.
  • 멀티미디어 삽입이 불편하다
    위지윅 에디터에서 이미지를 삽입할 때는, 보통 이미지 업로드 버튼을 이용해서 이미지를 삽입합니다. 하지만 마크다운은 그저 텍스트만 입력 가능하기 때문에, 이미지를 삽입하는 것과 이미지를 업로드하고, 그 주소를 따오는 과정들이 모두 분리되어 있습니다. 그래서 마크다운을 이용해서 블로그의 글을 작성할 때 가장 불편한 것이 바로 이미지를 삽입할 때입니다. 하지만 유튜브 등의 외부 동영상을 삽입할 때는 위지윅 에디터를 쓰는 것과 크게 다르지 않습니다.

마크다운 문법

제목

# 을 하나 쓰면 HTML의 <H1> 태그이고 #을 2개쓰면 <H2> 태그를 의미합니다. #은 총 6개까지 사용할 수 있고 #이 늘어날 때 마다 글씨가 작아집니다.

# 제목
## 부제목
### 소제목

번호가 없는 리스트

* 목록 
* 목록 1
- 다른 목록
- 다른 목록 1
+ 다른 목록 3

번호가 있는 리스트

1 첫 번쨰
2 두 번째
3 세 번째
5 다섯 번째
4 여섯 번째 

반드시 숫자를 맞춰 사용할 필요는 없습니다.

기울여진 글씨

*텍스트*
OR
_텍스트_

굵은 글씨

**텍스트**
OR
__텍스트__

인용

> 텍스트

인용문안에 인용문을 또 사용하려면 >을 추가하면 됩니다.

인라인 링크

[텍스트](링크주소)

참조링크

[텍스트][참조명]
 
[참조명]: 링크주소

이미지

![텍스트](이미지링크)

수평선

_, *, - 을 3개 이상씩 나열
 
---
***
___

코드

\`코드 내용\`

코드블럭

앞에 공백 4개 이상 삽입


+ Random Posts