GOGS : Go 언어로 만들어진, Github 비스무레하게 운용할 수 있도록 한 웹서비스 어플리케이션.

개요

  • 사설 Git 서버의 웹서비스 소프트웨어 중 한 종류.
  • 홈페이지 : https://gogs.io
  • 특징 : 설치, 사용이 매우 쉽고 UI가 깜찍하다.

설치

  • DB가 필요하므로, 없다면 먼저 설치해 준다. 여러 종류를 지원해 주므로 확인.
  • 여기서는 일단 제일 간단한 SQLITE3를 써 보자. (이미 설치되어 있을수도 있다.)
sudo apt install sqlite3
  • 여기서 바이너리를 다운받아 적당한 위치에 압축을 푼다. 여기서는 ~/gogs로 해 본다.
  • 터미널에서 압축을 푼 장소로 와서 다음 명령을 때린다.
./gogs web
  • 웹브라우저에서 주소 localhost:3000/install으로 최초 설정 페이지가 나타난다.

설정

  • 바이너리 배포본에서는 MySQL, PostgreSQL, SQLite3 중에서 선택할 수 있다.
  • 여기서는 SQLite3으로 선택 해 본다.
  • ‘경로’는 적당하게 절대경로로 이렇게 넣어줘 보자. /home/dymaxionkim/gogs/data/gogs.db
  • ‘애플리케이션 이름’은 적절하게 넣는다.
  • ‘저장소 최상위 경로’도 절대경로로 이렇게 넣어줘 보자(디폴트). /home/dymaxionkim/gogs-repositories
  • ‘데몬 사용자 계정’은 현재 자신의 PC 계정을 넣는다. dymaxionkim
  • ‘도메인’은 일단 디폴트로. localhost
  • ‘SSH 포트’도 디폴트로 22, ‘HTTP 포트’는 좀 바꿔서 3333
  • ‘애플리케이션 URL’은 http://localhost:3333/
  • ‘로그경로’는 디폴트로 /home/dymaxionkim/gogs/log
  • 그리고 기타 다른 설정들도 그냥 디폴트로 놔둔다.
  • GOGS 설치하기 버튼을 누른다.
  • 터미널에 First-time run install finished! 같은 메시지를 확인.
  • 터미널에서 Ctrl+c를 눌러서 gogs를 종료했다가 ./gogs web을 쳐서 다시 실행.
  • 이제 웹브라우저에서 설정한 URL인 http://localhost:3333/으로 접속.
  • 최초 가입자가 곧 관리자 권한을 획득한다고 한다.

추가 설정

파일 업로드 제한 완화

  • 파일 업로드 사이즈 제한이 겨우 3MB이고, 한 번에 올릴 수 있는 파일 개수는 5개로 되어 있어서, 그보다 더 큰 파일은 아예 업로드가 안된다.
  • 설정 파일은 /home/dymaxionkim/gogs/custom/conf/app.ini 파일로 파악되는데, 여기에 파일 사이즈 제한 항목이 안 보인다.
  • 그래서 이곳의 내용을 참조하여, 다음 내용을 삽입해 넣어 본다.
[repository.upload]
; Maximum size of each file in MB
FILE_MAX_SIZE = 1024
; Maximum number of files per upload
MAX_FILES = 1024
  • 설정이 잘 적용됨이 확인된다.

하위폴더 추가시 불편함

  • gogs 웹 상에서, 파일업로드 단추를 누르고 하위폴더를 추가한 후 그냥 커밋해 보니 404에러 페이지가 뜨고 실패한다. 빈 폴더 추가가 안되는 Github와 같은 특성인 듯 하다.
  • 그 대신, 파일업로드 단추를 누르고 하위폴더를 추가한 후, 곧바로 여기에 파일들을 드래그&드랍해서 올리고 커밋해 보니 문제없이 잘 된다.
  • 그리고 탐색기상에서 안에 파일이 들어 있는 폴더를 찝어서 드래그&드랍 하니깐, 폴더는 사라지고 그 안의 파일들이 그냥 섞여들어가 버린다. 이렇게 하면 안 되겠구나.

협업 모델

  • git을 이용한 협업 워크플로우 배우기
    • Centralized Workflow
    • Feature Branch Workflow
    • Gitflow Workflow
    • Forking Workflow
  • 이상 4가지 모델 중, 첫번째와 네번째는 별도의 브랜치 작업이 필요 없다. 2,3번째 모델은 복잡한 브랜치 생성 및 통합 관리가 필요해지므로 정교한 대신 상당히 복잡해진다.
  • 즉 구조설계자 입장에서는, 소프트웨어 개발자와는 달리 버전의 정교한 통제 까지는 필요없다. 그렇게 잘게 쪼개서 커밋을 하게 되면 저장소 공간만 기하급수적으로 커질 것이다. (이진파일 위주이기 때문)
  • 마지막의 Forking Workflow는 가장 흔히 먼저 접할 수 있는 Github 커뮤니티 개발에서 Fork, Pull Request에만 의존하는 방법이므로 워크플로우가 상당히 단순해진다. 설계자가 알아야 할 개념도 너무 추상적이지 않아서 이해하기가 쉬울 것 같다.