머가필요해

GIT을 사용하다 보면 자주 사용하는 명령어 중 하나가 바로 [ git log ]이다.

commit list를 보기 위한 목적도 있지만, 현재 HEAD가 어디에 있는지 브랜치 상황은 어떤지 등도 확인할 수가 있다. 물론 가장 큰 이유는 언제 어떤 commit이 들어왔는지 확인하는 것이다.

문제는 git log 명령에 대한 출력 결과에 정말 다양한 취향이 존재하며, 이를 만족시키기 위해 다양한 옵션과 함께 자유롭게 결과 형식을 꾸밀 수 있는 pretty-format을 지원하고 있다.

많이 아는 사람은 입맛에 맞게 꾸미면 되지만, 일반적인 사용자들은 너무 많은 옵션을 어떻게 사용해야 할지 어렵기만 할 뿐이다.


개인적으로 가장 자주 사용하는 옵션은 아래와 같다.

출력 결과는 아래와 같다. 아래에 표시는 안했지만, 색도 입혀져 있다.

일반적으로는 위와 같은 출력만으로도 대부분의 상황은 해결이 된다. commit list도 보여주고 있고 브랜치의 모습도 그래프 형식으로 보여주고 있으며 commit comments도 잘 보여주고 있다. 거기에다가 HEAD의 위치나 브랜치의 위치도 잘 보여주고 있다.

하지만, 개인적으로 조금 부족한 부분이 있어서 아쉬움이 좀 남았다. 그래서 이런 저런 방안을 찾던 중 git log에서도 지원을 하고 있는 pretty-format에 대해서 알아보았다.

그러던 중 웹에서 몇 몇 훌륭한 예시들을 보게 되었고, 개인적인 입맛에 맞게 살짝 변형을 해보았다.

앞에서 사용한 것과 조금 차이가 있다. 일단 날짜가 나오고 commiter 계정 정보도 나온다. 물론 앞에서 사용했던 옵션에서 보여주고 있는 정보들은 여전히 나오고 있다.

그런데, 여전히 문제가 하나 있다. log를 확인하고 싶을 때마다 저 옵션을 계속 입력할 수는 없다. 저걸 외워서 하겠다라는 사람이 있으면 대단한 것이 아니라 무식한 것이다.

그래서 사용할 수 있는 방법이 바로 alias를 활용하는 것이다. 한 번 살펴보자.

사용법은 간단하고도 유용하다.

일반 명령어처럼 사용할 수가 있다. 더불어 뒤에 옵션도 추가로 사용할 수 있다.


위 샘플을 가지고 각자 취향에 맞는 log 옵션을 찾아보길 권한다. 정말 한 번 고생을 해 놓으면 정말 편리하다 !!!

이제는 어느정도 안정화가 된 것으로 보이는 GIT이지만,
아직도 종종 업데이트가 올라온다.

실제 업무에 이러한 도구를 도입할 때에 문제 중 하나가 이러한 업데이트이다.
버전 間 차이점이 많으면 사용 버전끼리의 충돌 이슈가 발생할 수 있기 때문이다.

그래서 실무에서는 사용할 버전을 하나 정해놓고 모두 해당 버전을 사용하게 가이드하곤 한다.

그리고 새로운 버전이 올라오면 해당 버전을 반영할 필요가 있을지 먼저 검증을 하고,
필요한 기능이 있다면 예전 버전과의 호환성 검증을 한 이후에 배포를 해야한다.

 

Git 1.8.1.3 Release Notes =========================  Fixes since v1.8.1.2 --------------------   * The attribute mechanism didn't allow limiting attributes to be    applied to only a single directory itself with "path/" like the    exclude mechanism does.  The fix for this in 1.8.1.2 had    performance degradations.   * Command line completion code was inadvertently made incompatible with    older versions of bash by using a newer array notation.   * Scripts to test bash completion was inherently flaky as it was    affected by whatever random things the user may have on $PATH.   * A fix was added to the build procedure to work around buggy    versions of ccache broke the auto-generation of dependencies, which    unfortunately is still relevant because some people use ancient    distros.   * We used to stuff "user@" and then append what we read from    /etc/mailname to come up with a default e-mail ident, but a bug    lost the "user@" part.   * "git am" did not parse datestamp correctly from Hg generated patch,    when it is run in a locale outside C (or en).   * Attempt to "branch --edit-description" an existing branch, while    being on a detached HEAD, errored out.   * "git cherry-pick" did not replay a root commit to an unborn branch.   * We forgot to close the file descriptor reading from "gpg" output,    killing "git log --show-signature" on a long history.   * "git rebase --preserve-merges" lost empty merges in recent versions    of Git.   * Rebasing the history of superproject with change in the submodule    has been broken since v1.7.12.   * A failure to push due to non-ff while on an unborn branch    dereferenced a NULL pointer when showing an error message.  Also contains various documentation fixes.

 

뭔가 많이 고쳐진 것이면 바람직하게 보여야 하는데... 아직도 고칠 것이 많은가~하는 불안감도 살짝 있다는...

리눅스의 터미널을 사용하다보면 아주 유용한 기능 중 하나가 바로 자동 완성 기능이다.
명령어 일부를 입력하다가 [ tab ] 키를 누르면 나머지 부분을 자동 완성해주면 정말 편하게 사용할 수 있는 것이다.

특히 경로의 디렉토리 또는 파일 이름을 자동 완성해주면 정말, 정말 편하다.

그런데, Git도 자동완성 기능을 사용할 수 있다!!!


     - git source 파일 중에 자동완성을 위한 파일이 존재 한다.
     - 이를 필요한 곳에 복사를 해넣으면 된다.

$ cd /srv/install/git/git-v1.7.11.2/
$ sudo cp ./contrib/completion/git-completion.bash /etc/bash_completion.d/

     - 위와 같이 복사해 넣고 터미널을 다시 실행하면 된다(물론 source 명령어로 읽어들여도 된다).

     - 그러면, [ git che ] 정도만 입력하고 [ tab ] 키를 누르면 그와 관련한 명령어들이 나열된다.
     - 한 두 글자 더 입력하고 [ tab ] 키를 누르면 자동완성 되기도 한다.

     - 옵션 등도 자동으로 안내를 해주고 정말 유용한 기능이다.


이상~!

     - "gerrit2" 계정을 만들고 gerrit-2.4.1.war 파일을 해당 계정 소유로 만든 후 gerrit2 계정으로 su하자.




5. apache

     - 이번에는 웹서버로 apache로 셋팅을 해보겠다.
     - 나중에 시간이 잠시나면 꼭 nginx 환경에서 다시 해보도록 하겠다.

     - 설치를 했으면 확인을 하자.

     - Gerrit에서는 웹서버의 proxy 기능을 요구한다.

     - apache2의 proxy 모듈을 추가로 설치를 해주고,

     - 웹서버 준비는 여기까지 끝~



6. Gerrit Install

     - 이제 준비 작업은 모두 끝났다. 설치를 진행하면 된다.

     - Gerrit의 기본적인 구성은 Jenkins와 같은 *.war 파일 구동방식이다.
     - 차이가 있다면, init 과정이 있다는 점 정도?!

     - 설치과정을 진행하기 전에 권한을 맞추기 위한 선행 준비를 먼저 하자.

     - 위에서 명시한 디렉토리는 gerrit2 계정 권한으로 미리 만들어 두었다.

     - 이어서 계속 진행하자.

     - 인증 방식은 [ http ]로 정했다.
     - SMTP 설정은 gmail을 활용하기로 정했다. (이메일 주소는 살짝 지웠다 ^^ 다 알겠지만서도...)

     - 나중에 설정 내용은 변경할 수 있으므로 최대한 기본값으로 정했다.

     - 그런데, 마지막 줄이 마음에 걸린다. [ No protocol specified ]




7. Configuration

     - 여기에서 바로 Gerrit이 실행되면 좋겠는데, 몇 가지 더 설정할 것들이 많다.

     - 앞에서도 언급을 했지만, 우리는 Apache의 Proxy를 활용하여 Gerrit을 띄울 것이다.
     - 그리고 Apache의 http authentication을 적용할 것이다.

     - 우선 관리자 계정 하나를 만들어 넣자.

     - 앞의 설치 과정을 통해 만들어진 gerrit site 의 etc 디렉토리에 passwords 파일을 생성하는 것이다.
     - 앞으로 Gerrit 웹페이지는 이 파일을 이용하여 인증을 하게 된다.

     - Apache의 VirtualHost도 설정을 해주자.

     - 위에서 각 포트가 중요한데, VirtualHost 에서는 8081 포트를 사용하고
     - Proxy에서는 8080 포트를 사용한다.

     - 추가로 sites-enabled 디렉토리에 동적링크도 만들어주자.

     - 위와 같이 설정을 하였으면 Apache의 port 설정에도 추가해줘야 한다.

     - 위와 같이 8081 포트에 대해서 설정을 추가로 적어주면 된다.

     - gerrit 의 설정값도 다시 한 번 살펴봐야 한다.

     - 위에서 빨간색으로 표시한 부분만 수정, 추가하면 된다.



8. restart

     - 재시작을 한 번 해보자.

     - 이제 웹으로 확인을 해보자.

     - [ http://localhost:8081 ] 주소로 접속을 하면 위와 같이 이름과 암호를 물어본다.
     - 앞에서 "htpasswd"로 만든 계정을 이용해서 로그인하면 된다.

     - 드디어 길고 긴 과정을 거쳐서 gerrit의 화면이 나왔다.



9. Sign Out

     - 이렇게 설치를 했는데, 가장 원초적인 문제가 있다. 바로 [ Sign Out ]이 동작하지를 않는다.

     - 앞에서 [ gerrit.conf ] 파일을 수정할 때 넣은 [ canonicalWebUrl = http://localhost:8081/ ] 때문에 발생했다.
     - 하지만, 그 부분을 없애면 기본적인 동작도 하지 않는다.

     - 이 부분에 대한 해결책은 아직 찾지 못했다.
     - 찾게 되는 즉시 업데이트하도록 하겠다.