bookmark_borderGit 도구 – 히스토리 단장하기

히스토리 단장하기

Git으로 일하다 보면 어떤 이유로든 커밋 히스토리를 수정해야 할 때가 있다. 결정을 나중으로 미룰 수 있던 것은 Git의 장점이다. Staging Area로 커밋할 파일을 고르는 일을 커밋하는 순간으로 미룰 수 있고 Stash 명령으로 하던 일을 미룰 수 있다. 게다가 이미 커밋해서 결정한 내용을 수정할 수 있다. 그리고 수정할 수 있는 것도 매우 다양하다. 커밋들의 순서도 변경할 수 있고 커밋 메시지와 커밋한 파일도 변경할 수 있다. 여러 개의 커밋을 하나로 합치거나 반대로 커밋 하나를 여러 개로 분리할 수도 있다. 아니면 커밋 전체를 삭제할 수도 있다. 하지만, 이 모든 것은 다른 사람과 코드를 공유하기 전에 해야 한다.

이 절에서는 사람들과 코드를 공유하기 전에 커밋 히스토리를 예쁘게 단장하는 방법에 대해서 설명한다.

마지막 커밋을 수정하기

히스토리를 단장하는 일 중에서는 마지막 커밋을 수정하는 것이 가장 자주 하는 일이다. 기본적으로 두 가지로 나눌 수 있는데 하나는 커밋 메시지를 수정하는 것이고 다른 하나는 파일 목록을 수정하는 것이다.

커밋 메시지를 수정하는 방법은 매우 간단하다.

$ git commit --amend

이 명령은 자동으로 텍스트 편집기를 실행시켜서 마지막 커밋 메시지를 열어준다. 여기에 메시지를 바꾸고 편집기를 닫으면 편집기는 바뀐 메시지로 마지막 커밋을 수정한다.

커밋하고 난 후 새로 만든 파일이나 수정한 파일을 가장 최근 커밋에 집어넣을 수 있다. 기본적으로 방법은 같다. 파일을 수정하고 git add 명령으로 Staging Area에 넣거나 git rm 명령으로 추적하는 파일 삭제한다. 그리고 git commit --amend 명령으로 커밋하면 된다. 이 명령은 현 Staging Area의 내용을 이용해서 수정한다.

이때 SHA-1 값이 바뀌기 때문에 과거의 커밋을 변경할 때 주의해야 한다. Rebase와 같이 이미 Push 한 커밋은 수정하면 안 된다.

커밋 메시지를 여러 개 수정하기

최근 커밋이 아니라 예전 커밋을 수정하려면 다른 도구가 필요하다. 히스토리 수정하기 위해 만들어진 도구는 없지만 rebase 명령을 이용하여 수정할 수 있다. 현재 작업하는 브랜치에서 각 커밋을 하나하나 수정하는 것이 아니라 어느 시점부터 HEAD까지의 커밋을 한 번에 Rebase 한다. 대화형 Rebase 도구를 사용하면 커밋을 처리할 때마다 잠시 멈춘다. 그러면 각 커밋의 메시지를 수정하거나 파일을 추가하고 변경하는 등의 일을 진행할 수 있다. git rebase 명령에 -i 옵션을 추가하면 대화형 모드로 Rebase 할 수 있다. 어떤 시점부터 HEAD까지 Rebase 할 것인지 인자로 넘기면 된다.

마지막 커밋 메시지 세 개를 모두 수정하거나 그 중 몇 개를 수정하는 시나리오를 살펴보자. `git rebase -i`의 인자로 편집하려는 마지막 커밋의 부모를 `HEAD~2^`나 `HEAD~3`로 해서 넘긴다. 마지막 세 개의 커밋을 수정하는 것이기 때문에 `~3`이 좀 더 기억하기 쉽다. 그렇지만, 실질적으로 가리키게 되는 것은 수정하려는 커밋의 부모인 네 번째 이전 커밋이다.

$ git rebase -i HEAD~3

이 명령은 Rebase 하는 것이기 때문에 메시지의 수정 여부에 관계없이 HEAD~3..HEAD 범위에 있는 모든 커밋을 수정한다. 다시 강조하지만 이미 중앙서버에 Push 한 커밋은 절대 고치지 말아야 한다. Push 한 커밋을 Rebase 하면 결국 같은 내용을 두 번 Push 하는 것이기 때문에 다른 개발자들이 혼란스러워 할 것이다.

실행하면 Git은 수정하려는 커밋 목록이 첨부된 스크립트를 텍스트 편집기로 열어준다.

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file

# Rebase 710f0f8..a5f4a0d onto 710f0f8
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

이 커밋은 모두 log 명령과는 정반대의 순서로 나열된다. log 명령을 실행하면 아래와 같은 결과를 볼 수 있다.

$ git log --pretty=format:"%h %s" HEAD~3..HEAD
a5f4a0d added cat-file
310154e updated README formatting and added blame
f7f3f6d changed my name a bit

위 결과의 역순임을 기억하자. 대화형 Rebase는 스크립트에 적혀 있는 순서대로 `HEAD~3`부터 적용하기 시작하고 위에서 아래로 각각의 커밋을 순서대로 수정한다. 순서대로 적용하는 것이기 때문에 제일 위에 있는 것이 최신이 아니라 가장 오래된 것이다.

특정 커밋에서 실행을 멈추게 하려면 스크립트를 수정해야 한다. `pick`이라는 단어를 ‘edit’로 수정하면 그 커밋에서 멈춘다. 가장 오래된 커밋 메시지를 수정하려면 아래와 같이 편집한다.

edit f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file

저장하고 편집기를 종료하면 Git은 목록에 있는 커밋 중에서 가장 오래된 커밋으로 이동하고, 아래와 같은 메시지를 보여주고, 명령 프롬프트를 보여준다.

$ git rebase -i HEAD~3
Stopped at f7f3f6d... changed my name a bit
You can amend the commit now, with

       git commit --amend

Once you’re satisfied with your changes, run

       git rebase --continue

명령 프롬프트가 나타날 때 Git은 Rebase 과정에서 현재 정확히 뭘 해야 하는지 메시지로 알려준다. 아래와 같은 명령을 실행하고

$ git commit --amend

커밋 메시지를 수정하고 텍스트 편집기를 종료하고 나서 아래 명령을 실행한다.

$ git rebase --continue

이렇게 나머지 두 개의 커밋에 적용하면 끝이다. 다른 것도 pick을 edit로 수정해서 이 작업을 몇 번이든 반복할 수 있다. 매번 Git이 멈출 때마다 커밋을 정정할 수 있고 완료할 때까지 계속 할 수 있다.

커밋 순서 바꾸기

대화형 Rebase 도구로 커밋 전체를 삭제하거나 순서를 조정할 수 있다. “added cat-file” 커밋을 삭제하고 다른 두 커밋의 순서를 변경하려면 아래와 같은 Rebase 스크립트를

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file

아래와 같이 수정한다.

pick 310154e updated README formatting and added blame
pick f7f3f6d changed my name a bit

수정한 내용을 저장하고 편집기를 종료하면 Git은 브랜치를 이 커밋의 부모로 이동시키고서 `310154e`와 `f7f3f6d`를 순서대로 적용한다. 명령이 끝나고 나면 커밋 순서가 변경됐고 “added cat-file” 커밋이 제거된 것을 확인할 수 있다.

커밋 합치기

대화형 Rebase 명령을 이용하여 여러 개의 커밋을 꾹꾹 눌러서 커밋 하나로 만들어 버릴 수 있다. Rebase 스크립트에 자동으로 포함된 도움말에 설명이 있다.

#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

‘`pick’이나 ‘`edit‘말고 “squash’’를 입력하면 Git은 해당 커밋과 바로 이전 커밋을 합칠 것이고 커밋 메시지도 Merge 한다. 그래서 3개의 커밋을 모두 합치려면 스크립트를 아래와 같이 수정한다.

pick f7f3f6d changed my name a bit
squash 310154e updated README formatting and added blame
squash a5f4a0d added cat-file

저장하고 나서 편집기를 종료하면 Git은 3개의 커밋 메시지를 Merge 할 수 있도록 에디터를 바로 실행해준다.

# This is a combination of 3 commits.
# The first commit's message is:
changed my name a bit

# This is the 2nd commit message:

updated README formatting and added blame

# This is the 3rd commit message:

added cat-file

이 메시지를 저장하면 3개의 커밋이 모두 합쳐진 커밋 한 개만 남는다.

커밋 분리하기

커밋을 분리한다는 것은 기존의 커밋을 해제하고(혹은 되돌려 놓고) Stage를 여러 개로 분리하고 나서 그것을 원하는 횟수만큼 다시 커밋하는 것이다. 예로 들었던 커밋 세 개 중에서 가운데 것을 분리해보자. 이 커밋의 ‘`updated README formatting and added blame’을 ‘`updated README formatting‘과 “added blame’’으로 분리하는 것이다. rebase -i 스크립트에서 해당 커밋을 “edit”로 변경한다.

pick f7f3f6d changed my name a bit
edit 310154e updated README formatting and added blame
pick a5f4a0d added cat-file

저장하고 나서 명령 프롬프트로 넘어간 다음에 그 커밋을 해제하고 그 내용을 다시 두 개로 나눠서 커밋하면 된다. 저장하고 편집기를 종료하면 Git은 제일 오래된 커밋의 부모로 이동하고서 f7f3f6d`과 `310154e`을 처리하고 콘솔 프롬프트를 보여준다. 여기서 커밋을 해제하는 `git reset HEAD^ 라는 명령으로 커밋을 해제한다. 그러면 수정했던 파일은 Unstaged 상태가 된다. 그다음에 파일을 Stage 한 후 커밋하는 일을 원하는 만큼 반복하고 나서 `git rebase –continue`라는 명령을 실행하면 남은 Rebase 작업이 끝난다.

$ git reset HEAD^
$ git add README
$ git commit -m 'updated README formatting'
$ git add lib/simplegit.rb
$ git commit -m 'added blame'
$ git rebase --continue

나머지 a5f4a0d 커밋도 처리되면 히스토리는 아래와 같다.

$ git log -4 --pretty=format:"%h %s"
1c002dd added cat-file
9b29157 added blame
35cfb2b updated README formatting
f3cc40e changed my name a bit

다시 강조하지만 Rebase 하면 목록에 있는 모든 커밋의 SHA-1 값은 변경된다. 절대로 이미 서버에 Push 한 커밋을 수정하면 안 된다.

filter-branch는 포크레인

수정해야 하는 커밋이 너무 많아서 Rebase 스크립트로 수정하기 어려울 것 같으면 다른 방법을 사용하는 것이 좋다. 모든 커밋의 이메일 주소를 변경하거나 어떤 파일을 삭제하는 경우를 살펴보자. `filter-branch`라는 명령으로 수정할 수 있는데 Rebase가 삽이라면 이 명령은 포크레인이라고 할 수 있다. `filter-branch`도 역시 수정하려는 커밋이 이미 공개돼서 다른 사람과 함께 공유하는 중이라면 사용하지 말아야 한다. 하지만, 잘 쓰면 꽤 유용하다. `filter-branch`가 유용한 경우를 예로 들어 설명하기 때문에 여기에서 대충 어떤 경우에 유용할지 배울 수 있다.

모든 커밋에서 파일을 제거하기

갑자기 누군가 생각 없이 git add . 같은 명령을 실행해서 공룡 똥 덩어리를 커밋했거나 실수로 암호가 포함된 파일을 커밋해서 이런 파일을 다시 삭제해야 하는 상황을 살펴보자. 이런 상황은 생각보다 자주 발생한다. filter-branch`는 히스토리 전체에서 필요한 것만 골라내는 데 사용하는 도구다. `filter-branch`의 `--tree-filter`라는 옵션을 사용하면 히스토리에서 `passwords.txt 파일을 아예 제거할 수 있다.

$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
Ref 'refs/heads/master' was rewritten

--tree-filter 옵션은 프로젝트를 Checkout 한 후에 각 커밋에 명시한 명령을 실행시키고 그 결과를 다시 커밋한다. 이 경우에는 각 스냅샷에 passwords.txt 파일이 있으면 그 파일을 삭제한다. 실수로 편집기의 백업파일을 커밋했으면 `git filter-branch –tree-filter rm -f *~ HEAD`라고 실행해서 삭제할 수 있다.

이 명령은 모든 파일과 커밋을 정리하고 브랜치 포인터를 다시 복원해준다. 이런 작업은 테스팅 브랜치에서 실험하고 나서 master 브랜치에 적용하는 게 좋다. filter-branch 명령에 --all 옵션을 추가하면 모든 브랜치에 적용할 수 있다.

하위 디렉토리를 루트 디렉토리로 만들기

다른 VCS에서 코드를 임포트하면 그 VCS만을 위한 디렉토리가 있을 수 있다. SVN에서 코드를 임포트하면 trunk, tags, branch 디렉토리가 포함된다. 모든 커밋에 대해 trunk 디렉토리를 프로젝트 루트 디렉토리로 만들 때도 filter-branch 명령이 유용하다.

$ git filter-branch --subdirectory-filter trunk HEAD
Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12)
Ref 'refs/heads/master' was rewritten

이제 trunk 디렉토리를 루트 디렉토리로 만들었다. Git은 입력한 디렉토리와 관련이 없는 커밋을 자동으로 삭제한다.

모든 커밋의 이메일 주소를 수정하기

프로젝트를 오픈소스로 공개할 때 아마도 회사 이메일 주소로 커밋된 것을 개인 이메일 주소로 변경해야 한다. 아니면 아예 git config`로 이름과 이메일 주소를 설정하는 것을 잊었을 수도 있다. 자신의 이메일 주소만 변경하도록 조심해야 한다. `filter-branch 명령의 --commit-filter 옵션을 사용하여 해당 커밋만 골라서 이메일 주소를 수정할 수 있다.

$ git filter-branch --commit-filter '
        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
        then
                GIT_AUTHOR_NAME="Scott Chacon";
                GIT_AUTHOR_EMAIL="schacon@example.com";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

이메일 주소를 새 주소로 변경했다. 모든 커밋은 부모의 SHA-1 값을 가지고 있기 때문에 조건에 만족하는 커밋의 SHA-1값만 바뀌는 것이 아니라 모든 커밋의 SHA-1 값이 바뀐다.

출처 :https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-%ED%9E%88%EC%8A%A4%ED%86%A0%EB%A6%AC-%EB%8B%A8%EC%9E%A5%ED%95%98%EA%B8%B0

bookmark_bordergitlab 자동 백업 하기

1. 수동 백업 / 복구

깃랩은 백업을 제공한다

백업은

sudo gitlab-rake gitlab:backup:create

하면 /var/opt/gitlab/backups 에 백업파일이 생긴다

백업 경로 변경은

sudo gedit /etc/gitlab/gitlab.rb

파일을 열고

gitlab_rails[‘backup_path’] = “/var/opt/gitlab/backups”

를 찾아서 주석을 푼 다음 (# 제거) 경로를 알맞게 바꿔주면 된다

복구는

디비관련 프로세스를 꺼주고

sudo gitlab-ctl stop unicorn

sudo gitlab-ctl stop sidekiq

백업 파일 리스트를 보자
sudo ls -la /var/opt/gitlab/backups
 
drwx——  2 git  root  4096  3월 10 17:35 .
drwxr-xr-x 11 root root  4096  3월 10 16:00 ..
-rw-r–r–  1 git  git  81920  3월 10 17:27 1425976057_gitlab_backup.tar
그다음 파일을 선택해주면 된다
sudo gitlab-rake gitlab:backup:restore BACKUP=1425976057
중간에 한번 물어보는데 ‘yes’ 입력
그리고 다시 시작시켜준다 (뭔진 잘 모름 ㅋ)
sudo gitlab-ctl start
sudo gitlab-rake gitlab:satellites:create
sudo gitlab-rake gitlab:check SANITIZE=true

2. 자동 백업 설정

수동을 알아봤으니 자동으로 백업하는 방법도 알아보자

리눅스엔 크론탭이라고 좋은게 있다

주기적으로 뭔가를 실행하는 놈인듯

sudo vi /etc/crontab

크론탭 편집

다음처럼 추가해 주자

분/시간/날짜/달/요일/커맨드 순서다

0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create

-> 요건 매월 매일 02:00분에 백업을 하라는 얘기

0 2 1 * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create

-> 이건 매월 1일 두시

0 2 * * 1 /opt/gitlab/bin/gitlab-rake gitlab:backup:create

-> 이건 매주 월요일 두시 (1부터 월요일)

첫번째꺼 말고는 테스트는 안해봄ㅋㅋ 될꺼라 믿고 감

저장하고 크론탭 재시작

sudo /etc/init.d/cron restart

bookmark_borderJenkins(젠킨스)와 SonarQube(소나) 연동 설정

본 포스팅은 Jenkins(젠킨스)와 SonarQube(소나)가 설치되어 있다는 전제하에 정리한다.

! 설치전에 알아야 할 내용. 

SonarQube는 JDK버전에 맞춰 설치하여야 한다. Jenkins에서 설치하는 플러그인도 버전을 맞춰 설치해 주어야 한다.

본인은 JDK 1.7을 사용하므로 SonarQube 5.5버전을 설치하였고 젠킨스 플러그인은 2.4.4를 설치하였다.

(소나 플러그인의 현재 버전은 2.5이며 JDK 1.8 이상에서만 설치가 가능하다.)
플러그인은 젠킨스에서 최신 버전만 리스트업되므로 Archive 메뉴를 이용하여 해당 버전을 다운로드 받아 직접

설치 해 주어야 한다. 다운로드 받는 파일은 hpi 확장자를 갖는다.

  • Jenkins 버전 : 2.7.4
  • SonarQube 버전 : 5.5
  1. 젠킨스에서 연동에 필요한 플러그인을 설치한다.
    1.1. Jenkins 관리 ▶ 플러그인 관리 ▶ 설치가능 탭으로 이동
    1.2. 필터 입력란에 sonarqube를 입력한 후 SonarQube Plugin 체크
    1.3. 지금 다운로드하고 재시작 후 설치하기 버튼을 눌러 플러그인 설치
  2. 설치 한 후 젠킨스를 재 시작한다.
  3. 프로젝트 ▶ 구성 메뉴로 이동
  4. Build 항목에서 Execute SonarQube Scanner 선택
  5. 소나에 등록 할 프로젝트에서 필요한 정보를 설정한다.

※ 항목 별 설명

설정 정보는 필수 항목과 옵션 항목으로 구성되어 있으며 옵션 항목은 필요한 경우에만 설정하면 된다.

  • Task to run : 옵션 항목이며 필요한 경우 설정한다.
  • JDK : 프로젝트에서 사용하고 있는 JDK 버전을 선택(선택 항목에 없다면 Jenkins 관리▶ Global Tool Configuration 에서 설치)
  • Path to project properties : 옵션 항목이며 sonar-project.properties 파일을 지정하고자 한다면 설정.
  • Analysis properties : SonarQube에 프로젝트를 등록하고 분석하는데 필요한 프로퍼티 정보를 설정한다.
    프로퍼티 설정에 대한 자세한 내용은 아래를 참고.

# required metadata sonar.projectKey=my:project sonar.projectName=My project sonar.projectVersion=1.0 # path to source directories (required) sonar.sources=myproject/src/main/java # path to test source directories (optional) #sonar.tests=testDir1,testDir2 # path to project binaries (optional), for example directory of Java bytecode #sonar.binaries=binDir # optional comma-separated list of paths to libraries. Only path to JAR file and path to directory of classes are supported. #sonar.libraries=path/to/library.jar,path/to/classes/dir # Uncomment this line to analyse a project which is not a java project. # The value of the property must be the key of the language. sonar.language=java # Additional parameters #sonar.my.property=value

필수 설정 프로퍼티

  • sonar.projectKey
    소나에서 관리 할 프로젝트 키이며 prefix : suffix 형태로 설정한다. 굳이 : 을 사이에 넣을 필요는 없을것 같으나
    예제에서 구성 해 놓은대로 설정한다. 키 값은 중복되지 않도록 설정한다.
  • sonar.projectName
    프로젝트 명칭을 입력한다. 양식에 제약은 없는 듯 하다.
  • sonar.projectVersion
    프로젝트 버전을 입력한다.
  • sonar.sources
    Jenkins에서 빌드 된 소스 파일의 경로를 설정한다. Jenkins의 프로젝트 기본 경로 다음의 경로를 설정하면 된다.
    예) myproject/src/main/java
    (/var/lib/jenkins/job/project/workspace 뒤의 경로를 지정한다. workspace까지는 기본 경로임.)
    본인은 java 소스코드만 분석하고자 하여 java 패스까지 설정하였으나 html, javascript 등 스크립트 언어까지 분석하고자
    한다면 java와 스크립트 폴더 경로가 나누어지는 경로까지 설정한다.
    요즘 흔히쓰는 경로 구조는 src > main > java/webapp 형태이므로 src/main까지만 설정하면 된다.

출처: http://shy-blg.tistory.com/entry/Jenkins와-SonarQube-연동-방법 [소울메이커]

 

현재 내가 쓰는 설정

#프로젝트키
sonar.projectKey= AutoCAD_MPlot
#프로젝트 이름
sonar.projectName=AutoCAD_MPlot
#버전
sonar.projectVersion=1.0

# Comma-separated paths to directories with sources (required)
sonar.sources=dcsMPlot

# Encoding of the source files
sonar.sourceEncoding=euc-kr

# Path where Build Wrapper files were output to
sonar.cfamily.build-wrapper-output=build-wrapper-out

# Path to the code coverage xml report produced by Visual Studio coverage tool (codecoverage.exe)
sonar.cfamily.vscoveragexml.reportsPath=codeCoverage.xml
# scm 을 서버 환경 설정에서 off 햇더라도 켜져잇는것으로 인식되는것 같음.
sonar.scm.disabled=true

bookmark_border[Doxygen] Doxygen 사용법, 예제

Doxygen

참고

https://www.stack.nl/~dimitri/doxygen/manual/index.html : doxygen 메뉴얼

http://www.slideshare.net/arload/doxygen-33932243 : doxygen 사용법

 

테스트 환경

– ubuntu14.04 lts

– php

테스트 코드

Test.php, Etc.php, subFolder/Etc.php 만들었다. 코드는 없다.

Doxygen 이란?

doxygen 코드상의 주석을 통해 문서를 만들어내는 프로그램이다. doxygen 맞는 주석을 사용하면 따로 문서를 만들 필요 없이 주석만으로 문서를 만들 있기 때문에 문서 관리를 따로 필요가 없고 코드만 보고도 이해하기가 쉬워진다.

아래와 같이 html 문서를 만들 있다.

 

 

 

 

 

기본 주석법

doxygen 인식하는 주석법은

/**
*
주석
*
*
*/

이런 식으로 /** 주석 시작시 * 두번 줘야 한다.

방법 말고도 주석 법은 있다.

 

아래의 사이트를 보면 주석 방법에 대해 나와 있다.

https://www.stack.nl/~dimitri/doxygen/manual/docblocks.html#specialblock

 

클래스에 대한 주석

@brief

간략한 설명

@details

자세한 설명

@author

저작권자

@date

날짜

@version

버전

 

 

/**

*

* @brief 테스트를 위한 클래스이다.

* @details 내부에서 아무짓도 안한다.

* @author oncellboy

* @date 1234-12-12

* @version 0.0.1

*

*/

class Test{

}

 

 

출력 문석

 

 

 

 

메소드에 대한 주석

@brief

간략한 설명

@details

자세한 설명

@param

파라미터

@return

반환

@throws

발생 예외

 

/**

*

*        @brief 메서드 간략 설명

*        @details 메서드 자세한 설명

*        @param string a 파라미터 번

*        @param string b

*        이거는 테스트 파라미터

*

*        @return mixed|boolean

*  성공시 숫자, 실패시 false 반환

*

*        @throws ValidException 나쁜짓하면 예외발생

*

*/

public function add($a,$b)

{

$sum = $a + $b;

 

 

return $sum;

}

 

 

출력 문서

 

 

 

 

기타 주석

주석 설명 작성 출력

@todo

todo

todo 리스트를 따로 관리도 해준다.

@todo 다음주까지 해야할 업무

 

todo 리스트 관리

@todo 작성된 해당 클래스와 메소드를 알수 있다.

@bug

bug

bug 리스트를 따로 관리도 해준다.

@bug 반환이 언제나 false이다. 해결해야함


bug 리스트 관리

@bug 작성된 클래스와 메소드를 알수 있다.

@see

참고나 이것 저것 보여 줘야 하는것 @see 그냥 이것저것 보여줘야하는 것

 

_____|______

      |

 First Header  | Second Header

————- | ————-

Content Cell  | Content Cell

Content Cell  | Content Cell

 

@li

리스트 @li list 1

@li list 2

 

[내용](링크주소) 링크

클릭시 링크를 연다.

[내 블로그](http://onecellboy.tistory.com)

@code

@endcode

코드 표현  @code{.py}

#!/usr/bin/python

print “Hello World! 뜸금없는 파이썬 코드”

@endcode

 

@ref class

@ref namespace.class

참조

클래스 이름이나 네임스페이스가 포함되어 있는 경우 namespace.class 써준다.

참조 링크를 클릭시 해당 클래스의 문서 페이지로 이동한다.

@ref Etc

@ret subFolder.Etc

 

subFloder.Etc 클릭시 해당 클래스의 문서 페이지로 이동한다.

 

@n

주석 내에서 new line(개행) 이다. @see 개행할 것 @n 이다.  

 

 

작성 전체

<?php

 

 

require_once ‘./Etc.php’;

 

 

 

 

/**

*

* @brief 테스트를 위한 클래스이다.

* @details 내부에서 아무짓도 안한다.

* @author oncellboy

* @date 1234-12-12

* @version 0.0.1

*

*/

class Test{

 

public $test;

 

 

 

public function __construct()

{

 

}

 

 

 

public function show()

{

 

$etc = new Etc();

 

$str = $etc->getText();

 

print_r($str);

}

 

 

/**

*

*        @brief 메서드 간략 설명

*        @details 메서드 자세한 설명

*        @param string a 파라미터 번

*        @param string b

*        이거는 테스트 파라미터

*

*        @return mixed|boolean

*  성공시 숫자, 실패시 false 반환

*

*        @throws ValidException 나쁜짓하면 예외발생

*

*

*

*  @todo 다음주까지 해야할 업무

*

*  @bug 반환이 언제나 false이다. 해결해야함

*

*

*  @see 그냥 이것저것

*  보여줘야하는 것

*

*

*        First Header  | Second Header

*        ————- | ————-

*        Content Cell  | Content Cell

*        Content Cell  | Content Cell

*

*  @li list 1

*  @li list 2

*

*  [내 블로그](http://onecellboy.tistory.com)

*

*        @code{.py}

*  #!/usr/bin/python

*        print “Hello World! 뜸금없는 파이썬 코드”

*  @endcode

*

*  이 클래스를 사용합니다. @ref Etc @n

*  이 네임스페이스의 이 클래스를 사용합니다. @ret subFolder.Etc

*

*/

public function add($a,$b)

{

$sum = $a + $b;

 

 

return $sum;

}

}

 

 

출력 문서 전체

 

 

 

 

 

 

 


Doxygen 설치

$ sudo apt-get install doxygen doxygen-gui

 

 

Doxygen gui 실행

$ doxywizard

 

 

 

Doxygen GUI 설정

 

 

select : 소스의 위치를 지정

Pjorect name : 프로젝트 이름

Project viersion or id : 프로젝트 버전

Scan recursively : 소스 위치의 모든 하위 폴더까지 스캔(지정하지 않으면 하위폴더에 대한 문서는 생성 안함)

 

 

 

All Entities : 모든 엔트리

Include cross-referenced source code in the output : 함수마다 사용한 함수로의 링크를 생성

 

Select programming language to optimize the results for : 언어 지정

 

 

with navigation panel : 문서 왼쪽에 탐색 트리를 보여줌

 

 

 

Dot graphs to generate : 소스간의 관계를 GraphViz 표현해줌

 

 

 

OUTPUT_LANGUAGE : 출력 문서 언어

 

 

 

ALWAYS_DETAILDE_SEC : 항상 상세 정보를 보여줌

INLINE_INHERITED_MEMB : 소멸자와 상속자를 제외한 상속된 모든 멤버를 보여줌

 

 

EXTRACT_ALL : 소스코드의 모든 요소가 문서화 대상이

EXTRACT_PRIVATE : 클래스 내의 모든 private 멤버가 문서화 대상이

EXTRACT_STATIC : 클래스 내의 모든 static 멤버가 문서화 대상이

INLIVE_SOURCES : 함수 설명시 함수 코드를 보여줌

 

CLASS_DIAGRAMS : 클래스의 상속구조 다이어그램을 그림

UML_LOOK : 다이어그램을 UML 형식으로 그림

 

DOT_PATH : dot 프로그램(Graphviz) 위치를 지정

 

Graphviz 설치법  sudo apt-get install graphviz

설치 위치 확인 : which dot

 

 

 

문서 만들기

 

Run doxygen 클릭

 

Show HTML output으로 문서 확인

 

 

출처 :http://onecellboy.tistory.com/342

bookmark_borderDOSPrint 와 파이썬을 이용해 PrintFil 대체하기

이전 포스팅에서 말했듯이 PrintFil이 30일간 사용할 수 있는 셰어웨어라 30일이 지나면 민원서류를 pdf로 출력하지 못합니다.

 

이를 대체하기 위해 DOSPrint와 Python을 이용해봅시다.

 

1. DOSPrint: http://www.andtechnologies.com/index.php?q=downloads/free-software 에서 DOSPrint 다운

2. Python: https://www.python.org/downloads/ 에서 다운 (3.X대신 2.X를 사용합니다.)

 

DOSPrint를 받고 압축을 풀고 DOSPrintUI를 실행합니다.

 

그러면 트레이에 아이콘이 생기는데 오른쪽 클릭을 하고 Configure를 누릅니다.

 

그런 다음 LPT1 포트에 이전 포스팅에서 다운받아 생긴 HP Universal Printing PS를 선택합니다.

(다른 걸 선택해도 되는지는 잘 모르겠네요.)

 

 

OK를 눌러주면 DOSPrint는 세팅 완료입니다.

 

 

이제 Python을 설치하고 첨부파일을 받으세요.

 

그 뒤 Python IDLE를 열고, File-Open을 클릭한 뒤 첨부파일을 엽니다.

여기서 location 부분을 수정해줍니다. 파일을 저장할 경로입니다.

(초기에는 C드라이브에 통일했으나, 권한 문제때문에 수동으로 고쳤습니다)

위처럼 r'(경로)’ 이런 형식으로 적어주시면 됩니다. (뒤에 ‘\\’는 건드리지 마세요)

마지막에 \(백슬래시)가 들어가면 에러가 날 수 있으니 유의하세요.

 

location을 지정해준 뒤 F5를 누르면 실행됩니다.

 

 

첫 번째로 DOSPrint를 열었는지 확인합니다. 그랬다면 y를 입력고 엔터를 누릅니다.

(소문자 y가 입력될 때까지 무한반복됩니다.)

 

열었다면, 이제 민원서류 인쇄에서 HP Universal Printing PS로 출력합니다.

그 뒤 두 번째 질문에 대해 y를 입력합니다.

그 다음 파일명을 입력합니다.

파일은 파일명.ps로 지정해준 경로에 저장되는데, 파일이 이미 존재한다면 덮어씌어지니 주의하세요.

 

 

 

그러면 완성입니다!

 

 

이제 PrintFil 없이 ps 파일을 만들 수 있습니다.

 

파이썬 프로그래밍을 할 줄 아시면, 첨부파일을 참고해 코드를 새로 작성하셔도 무방합니다.

 

 

[+] 위 포스팅은 printFil이 설치된 적이 있는 환경에서 작성되었습니다.

얼마전 포맷을 한 뒤 printFil 설치 없이 다시 시도해보니 다음과 같은 에러가 떴습니다.

No such file or directory: ‘LPT1:’

이렇게 뜬다면 위에서 Python IDLE를 열지 말고, 탐색기에서 lpt_capt.py를 더블클릭해서 실행하면 검은 콘솔 창이 뜹니다.

콘솔 창에서 시도해주세요.

 

처음에는 안 떴는데 몇 분 지난 뒤 시도해보니 정상적으로 작동하는 듯 합니다.