삽질의 미학

File의 내용을 Table로 copy 하는 import 작업이다.

위와는 반대로 Table의 내용을 파일로 extract 하는 작업이다.

현재 application의 상태를 알려준다.

postgreql DB shell 을 연다.

일반 shell 을 연다.

관리하는 앱이 여러개라면 -a appname 을 붙여주면 된다.

 git workflow 중 centralized 방식에 대해 step-by-step 으로 실제 사례를 보도록 하겠습니다.

 간단한 시나리오는 다음과 같습니다.

 여러분과 함께할 두 명의 개발자, 철수와 영희가 고용되었습니다. 철수와 영희는 각각에 대한 기능을 개발할 것이고, 철수가 먼저 완성시키고 영희는 철수보다 늦은 죄로 conflict 를 경험하게 됩니다. 이를 해결하며 어떻게 중앙저장소의 commit history를 유지하는지 같이 보도록 합시다.

 이제 마침 영희도 개발을 끝냈습니다. 영희는 다음처럼 철수와 똑같이 push 하려고 시도할 것입니다.

 결국 push는 실행되지 않습니다. 어떻게 해야할까요?

 다음으로 영희가 할 일은 철수의 update 를 자기의 local 저장소로 당겨와야합니다.(pull) 그리고 local 변화를 통합한 후 새로 시도하는 것이 해결책입니다. 다음을 보면서 얘기도록 하겠습니다.

7. 영희의 rebase

영희는 git pull 을 사용하여 자신의 local 저장소에 중앙저장소의 최신 흐름 (여기서는 철수가 push한 commit들) 을 불러올 수 있습니다. 이 명령어는 svn update 와 유사하게 동작합니다. 

 --rebase 옵션은 아래 그림과 같이, 중앙저장소로부터의 변경사항을 동기화 시키고 난 후 영희(Mary)의 모든 commit을 master branch로 옮길 것을 미리 지정하는 역할을 합니다.

 이 옵션을 쓰지 않아도 pull 은 잘 동작합니다. 그러나 나중에 매번 불필요한 "merge commit"을 해야할 수도 있으므로 --rebase 옵션을 추천합니다. 이번 Centralized workflow에서는 merge commit 보다는 rebase가 항상 더 좋은 결과를 냅니다. (commit history 를 선형으로 유지하기 쉽기 때문입니다)

8. 영희의 conflict 해결법

 Rebase는 각각의 local commit을 master branch로 하나씩 전송하면서 동작합니다. 이는 곧 하나의 큰 merge commit에 대한 conflict를 해결하는 것 보다는 조그만 commit을 베이스로 conflict를 잡아내고 수정하는 것이 더 나음을 의미합니다. 또한 Rebase는 여러분의 commit에 좀 더 포커스를 맞추고, 프로젝트 history를 깨끗하게 만들어줍니다. 버그가 발생했을 때, 가능한 작은 임팩트를 주는 곳으로 roll back 하는 것이 훨씬 버그를 잡는데 유용합니다.

 설명이 길어졌는데, 결론은 commit을 자주 하라는 것입니다.

 다시 본론으로 돌아와서, 철수와 영희가 서로 관련없는 기능들을 개발했다면 위와 같은 rebase 과정들이 conflict를 만들어내진 않을 것입니다. 그러나 겹치는 부분이 있다면, git는 현재 commit에서 rebase 를 멈추고 다음과 같은 메시지를 내보일 것입니다.

 git의 장점 중 하나는, 누구나 merge conflict를 해결할 수 있다는데에 있습니다. 흔히 git status 명령어를 사용하면 어디가 문제인지 알 수 있는데, conflict가 생긴 파일은 다음처럼 unmerged path section 에 나타날 것입니다.

그러고난 후 영희는 그녀가 원하는대로 해당 파일을 수정할 것입니다. 수정이 끝난 후 아래처럼 다시 git add를 통해 파일을 stage 상태로 만들고, git rebase로 나머지 작업을 마무리 짓습니다.

 여러분이 여기까지 오셨는데도 이해를 거의 못했다고해서 당황할 필요는 없습니다. 단지 아래 명령어를 실행하는 것만으로도 여러분은 시작점으로 쉽게 돌아갈 수 있습니다. git pull --rebase

9. 마무리

위와 같이 영희의 동기화 작업이 끝나면, 그 변경작업들이 성공적으로 push 되어질 수 있을 것입니다.

Centralized Workflow

 분산 버전 컨트롤 시스템으로의 전환은 어려운 작업처럼 보이지만, 여러분은 이미 잘 돌아가는 workflow를 바꿀 필욘 요는 없습니다. 여러분의 팀은 subversion에서 하던 그 방법 그대로 프로젝트를 개발할 수 있습니다.

 그러나 개발 workflow를 위해 git를 사용하는 것은 SVN에 비해 몇몇의 장점을 갖고 있습니다.

 먼저, git는 모든 개발자의 local 에 전체 프로젝트 파일을 공통적으로 보내줍니다. 이런 환경은 각각의 개발자들이 독립적으로 일할 수 있게 합니다. 각각의 local 저장소에 commit 하고 원할 때 push 할 수 있다는 것이지요

 두번째로, 강력한 branch 기능과 merge 기능을 쓸 수 있다는 것입니다. SVN과 달리 git의 branch는 실수에도 안전한 메커니즘으로 디자인되어져있습니다. 저장소 간 코드를 합치거나 변화된 내용들을 공유하기가 훨씬 좋아진 것입니다.

<How it works>

 Centralized workflow는 Subversion 처럼 프로젝트의 모든 변화를 하나의 entry 로 보내는 중앙 저장소를 사용합니다. 단 차이점이 있다면 trunk 대신 master라고 부르는 기본 개발 branch가 있고, 모든 변화는 이 branch로 커밋된다는 것입니다. 그리고 Centralized workflow 방식은 master branch만 필요로합니다. 다른 branch는 쓰이지 않습니다.

 개발자는 중앙저장소를 clone하는 것으로부터 개발을 시작합니다. Clone하게 되면 프로젝트가 개발자의 local에도 만들어지는데, 이 안에서 SVN을 쓰는 것처럼 파일을 변경하고 커밋합니다. (그러나, 이런 새로운 commit 들은 local 에 저장되기때문에 개발자들은 철저히 중앙저장소와는 독립되어있습니다. 또한 이는 개발자가 merge 하기 좋은 시점에서 동기화할 수 있도록 전체 흐름을 지연시켜주는 역할을 하기도 합니다.)

 변경사항을 프로젝트로 내보내기위해, 개발자는 그들의 local 에 있는 master branch 를 중앙저장소로 "push" 합니다. 이는 svn commit 과 같은 의미를 갖고 있습니다. 차이점이 있다면 local에 저장된 모든 commit 까지 중앙저장소의  master branch로 보내집니다. 아래 그림을 보시면 되겠습니다.

 중앙저장소에 있는 3개의 commit들을 clone 하고 난후 master에서 2개의 commit 작업들을 했습니다. 그리고 중앙저장소로 push하게 되면 최종본만 날라가는 것이 아니라 그 이전의 새로운 commit 역시 중앙저장소로 보내집니다.

<Managing Conflicts>

 Centralized workflow에서 중앙 저장소는 곧 프로젝트 그 자체를 나타냅니다. 그렇기때문에 중앙저장소의 master 에 대한 commit history는 매우 주의를 요합니다. 만약 한 개발자의 local commit이 중앙저장소로부터 분리되어나와서 진행되었다면 git는 push 를 거부할 것입니다. 아래 그림을 보시면 됩니다.

 origin/Master 가 중앙저장소의 branch를 나타냅니다. 저 상황에서 local의 push는 conflict를 유발하게 됩니다.

 그 개발자가 본인이 개발한 기능을 push하기에 앞서, 다른사람들이 작업을 마친 최신의 central commit 를 받아와야할(fetch) 필요가 있겠죠. 이렇게 진행해나가다보면 완벽한 직선형의 workflow가 만들어지게되고 이는 전통적인 SVN의 workflow와 일치합니다.

 local의 변경사항을 push 하다가 conflict이 발생하면, git는 rebase 과정을 멈추고 conflict를 직접 해결할 기회(?)를 줍니다. commit 할 때 쓰던 git status, git add 명령어들로 conflict들을 정리할 수 있는데, 다음 블로그에서 centralized workflow 에 대한 실제 사용예를 보며 익혀보겠습니다.

gitflow 방식의 실제 사용법을 예로 들어가며 살펴보겠습니다.

아래 예는 release cycle 한 바퀴를 manage 하는 법을 다루고 있습니다. 또한 중앙저장소는 이미 만들어져있고 당신, 철수, 영희 세 명의 개발자가 프로젝트에 투입되었다고 가정합니다.

1. Develop branch 만들기

 가장 첫 번째로 할 일은 master branch (초록색)로 부터 develop branch (주황색)를 만드는 것입니다. local에서 빈 develop branch를 만들고 난 후 이를 서버로 push 하는 것이 가장 심플한 방법입니다.

 이제 develop branch에서 project의 개발을 이어나가면 됩니다. 그럼 철수와 영희도 이 branch를 알아야 따라오겠지요? 다음 명령어로 간단히 동기화 할 수 있습니다.

2. 철수와 영희의 새로운 Feature 시작하기

 이제 주황색 develop branch 로 부터 철수와 영희가 새로운 기능 추가 작업을 할 차례입니다. 주의해야할 것은 master에서 시작하는 것이 아니라 develop를 base로 삼아야한다는 것입니다.

 그들은 이제 그들 나름대로의 작업을 아래와 같이 수행해 나갈 것입니다.

3. 영희 Feature 작업 끝

 몇 번의 local commit이 끝나고 영희의 기능이 준비되었습니다. 만약 우리 팀이 pull request 방식을 사용한다면, 지금이 영희의 branch를 develop으로 merge 할 가장 적절한 시기입니다. pull request를 쓰지 않으면, 영희가 직접 local develop를 merge하고난 후 중앙저장소로 push하면 됩니다. 아래와 같이 말이죠.

첫 번째 커맨드는 merge하기 전 develop branch가 up-to-date(최신) 인지 확인하는 절차입니다. 다시 한번 강조하지만 바로 master로 feature를 merge 해서는 안됩니다. Conflict에 대한 해결법은 Centralized workflow와 같습니다. 이를 다룰때 링크를 넣겠습니다.

4. 영희의 release 준비 시작하기

 철수가 본인의 기능개발에 주력하고 있는 동안, 영희의 기능까지 반영한 첫 번째 공식 릴리즈 (official release)를 준비하라는 명령이 떨어졌습니다. 이제 영희는 release 준비를 위한 새로운 branch (노란색)를 만들어야합니다. 즉, release 버전을 만드는 것이 이 단계에서 할 일입니다.

 이 branch는 모든 것을 test해보고, release를 클린업하고, 문서를 업데이트하는 등 다가오는 release 날짜에 맞춰 준비할 것들을 하기 위한 공간입니다. 영희는 이 branch를 만들어 중앙저장소로 push하면 이제 release에 추가될 새로운 기능은 잠정적으로 중단됩니다. 즉, 지금 develop에 반영되지않은 모든 기능은 다음 release cylce이 올때까지 연기된다는 뜻입니다.

5. 영희가 release 준비를 끝냄

 release가 본격적으로 돌아갈 시기가 되었으면, 영희는 release branch(노란색)를 master(초록색) 와 develop (주황색) 으로 merge 합니다. 그리고 release branch를 삭제합니다. 사실 develop으로 다시 merge 시키는 것이 중요합니다. 왜냐하면 매우 critical한 업데이트가 release branch 에 추가될 수도 있는데, 그런 업데이트 사항들은 새롭게 개발되는 기능들에도 반드시 접근가능해야할 필요가 있기때문입니다. 만약 우리 팀이 전체적 코드리뷰를 한다면, 지금이 pull request를 할 이상적인 타이밍입니다.

Release branch는 마치 develop과 master 사이의 버퍼처럼 작용한다는 사실을 그림을 통해 알 수 있습니다.

추가적인 사항으로, 여러분이 master에 무언가를 merge할 때마다 반드시 태그를 달아야합니다. 알아보기 쉽게 다음과 같이 말이죠.

6. 긴급 유지보수 작업

 Release를 했는데, 치명적인 버그가 발견되었다는 보고가 들어왔습니다. 영희는 버그를 잡기위해 master로부터 유지보수할 branch를 만들어 issue들을 처리합니다. 그리고난 후 다시 바로 master에 merge합니다.

 Release branch 처럼 유지보수 branch도 develop에 포함되어야할만큼 중요한 업데이트 내용입니다. 따라서 영희는 develop branch에도 merge 하고 비로소 유지보수 branch를 삭제합니다.

GIT workflow

이 글은 Git의 기능들에 대해 어느 정도 알고 있다고 가정하고 작성되었습니다.

각각 GIT의 기능은 잘 알지만, 실제 프로젝트 상에서 어디서 시작을 해야할지, 언제 GIT로 구현해야할지에 대해 알기는 어려운 일입니다. 따라서 실제 기업에 속한 팀들의 Workflow를 조사했고 가장 흔히 사용되고 있는 몇 가지를 통해 GIT의 시작점을 제공하고자 합니다.

앞으로 이어질 GIT workflow를 읽으며 주의해야할 것은, 이 내용들은 철칙이 아니라 단지 가이드라인에 불과하다는 것입니다. 어떤 flow가 가능한지, 어떻게 다른 workflow들을 mix할 것인지 보여주기 위함이 이 글의 목적입니다.

여러분 각각 프로젝트에 맞는 Workflow들을 잘 선택하시기 바랍니다 ^^

먼저 4가지 Workflow들에 대해 먼저 간단히 설명하고, 그 다음 하나씩 살펴보도록 하겠습니다.

1. Centralized Workflow

 팀원들이 이미 서브버전(Subversion)이나 중앙집중식 서버관리에 익숙하다면, Centralized workflow는 완전히 새로운 방식(분산형) 에 대한 적응없이도 쉽게 Git를 경험하고 따라올 수 있습니다.

개념 : http://verbosa.tistory.com/16

예시 : http://verbosa.tistory.com/17

2. Feature Branch Workflow

이 방식은 새로운 feature (기능 추가) 에 대한 이슈를 branch 하나로 캡슐화 시키는 것입니다. Centralized workflow 위에 만들어지며 위 그림에서 초록색이 bug나 새로운 이슈를 나타내게 됩니다. 이는 pull request를 변화(기능 추가 및 수정에 따른) 에 대한 토론의 수단으로 활용할 수 있는 장점이 있습니다. 

3. Gitflow Workflow

 이 방식은 릴리즈 사이클의 흐름을 따릅니다. 즉, 각각의 독립된 branch (feature development, release preparation, maintenance) 로 운영되어지는데 이것이 release cycle에 맞춰져서 돌아간다고 보시면 되겠습니다.

 엄격한 branch 모델을 운영하는 것은 큰 프로젝트를 운영할 때 꼭 필요한 구조인데요, 해당 포스트에서 자세히 다루겠습니다.

개념 : 작성중

예시 : http://verbosa.tistory.com/15

4. Forking Workflow

 이 방식은 Git에 있는 branch 와 cloning 의 능력을 최대한 이용하며 장점을 취하는 분산형 workflow입니다. 많은 개발자로 구성된 팀을 관리하는데 있어 안전하고 믿을 수 있는 방법이기도 합니다. 따라서 오픈소스처럼 untrusted contributor에게 commit 권한을 허용하는 것도 가능해집니다.

개념 : 작성중

예시 : 작성중

$> heroku pg:promote HEROKU_POSTGRESQL_COLOR_URL -a appname

import dj_database_url
DATABASES = {'default': dj_database_url.config(default='postgres://localhost')}

비밀번호 및 호스트 정보가 보이지 않기때문에 보안상 유리하다.

class GameClaim(models.Model):
    target = models.ForeignKey(User)
    claimer = models.ForeignKey(User)
    isAccepted = models.BooleanField()

그러면 다음과 같은 오류를 내뱉게 된다.

Accessor for field 'target' clashes with related field 'User.gameclaim_set'. Add a related_name argument to the definition for 'target'.

Accessor for field 'claimer' clashes with related field 'User.gameclaim_set'. Add a related_name argument to the definition for 'claimer'.

일반적으로 FK를 만들면, Django는 gameclaim_set 이라는 reverse relation을 내부적으로 만들게 된다. 그런데, Gameclaim 안에 2개의 FK가 있기때문에 같은 gameclaim_set 이름의 충돌(Crash)이 나는 것이다. 해결책은 이 Reverse relation의 이름을 related_name을 이용하여 강제로 주는 것이다.

class GameClaim(models.Model):
    target = models.ForeignKey(User, related_name='gameclaim_targets')
    claimer = models.ForeignKey(User, related_name='gameclaim_users')
    isAccepted = models.BooleanField()

class User(models.Model):
    friendship = models.ManyToManyField("User", related_name = 'user_friendship')
    friendreq = models.ManyToManyField("User", related_name = 'user_friendreq')

manage.py 를 사용하여 Django의 Application에 사용자 고유의 action을 등록할 수 있다. 여기서는 저번 tutorial 에서 만들었던 polls app을 위한 커스텀 명령어 closepoll 을 만들어볼 것이다. 이를 위해 management/commands 를 어플리케이션 디렉토리에 추가한다. 그러면 장고는 그 명령어들을 폴더 내의 각각의 모듈에 알아서 등록해준다.

즉 polls 앱은 아래와 같은 구조를 가질 것이다.

polls/
    __init__.py
    models.py
    management/
        __init__.py
        commands/
            __init__.py
            _private.py
            closepoll.py
    tests.py
    views.py

이렇게 하면, closepoll 명령어는 polls 어플리게이션을 포함하는 어떤 프로젝트에서도 사용가능하게 만들어질 것이다.

_private.py 모듈은 명령어 커맨드를 관리하는 역할으로서, 명령어 자체로는 사용할수 없다.
closepoll.py 모듈을 사용하기 위해 하나의 요구조건이 있는데, BaseCommand 또는 그의 sub클래스를 상속받는 Command 클래스를 재정의해야한다는 것이다.

커맨드를 구현하기 위해, polls/management/commands/closepoll.py 를 다음과 같이 편집한다.

from django.core.management.base import BaseCommand, CommandError
from polls.models import Poll

class Command(BaseCommand):
    args = ''
    help = 'Closes the specified poll for voting'

    def handle(self, *args, **options):
        for poll_id in args:
            try:
                poll = Poll.objects.get(pk=int(poll_id))
            except Poll.DoesNotExist:
                raise CommandError('Poll "%s" does not exist' % poll_id)

            poll.opened = False
            poll.save()

            self.stdout.write('Successfully closed poll "%s"' % poll_id)

이제 python manage.py closepoll <poll_id> 를 써서 새로운 custom command를 사용할 수 있다.

handle() 매서드는 poll_ids에 해당하는 각각의 poll.opened 들을 모두 False 로 바꿔준다.
만약 유저가 존재하지 않는 polls 에 접근한다면 CommandError 가 일어날 것이다. 다만poll.opened attribute 는 tutorial에는 존재하지 않고, polls.models.Poll이 이 예제를 위해 추가된 것이다.

주어진 poll을 닫는 것 대신 지우고 싶을 때는 굳이 추가적인 command 등록 없이 closepoll 을 변경하면 된다. 이런 커스텀 option은 반드시 option_list 에 다음처럼 추가되어야한다.

from optparse import make_option

class Command(BaseCommand):
    option_list = BaseCommand.option_list + (
        make_option('--delete',
            action='store_true',
            dest='delete',
            default=False,
            help='Delete poll instead of closing it'),
        )

    def handle(self, *args, **options):
        # ...
        if options['delete']:
            poll.delete()
        # ...

위 예제의 delete옵션은 또한 dictionary로도 접근가능하다. ex ) option['delete']
optparse 파이썬 문서로 가면 make_option 사용법에 대해 알 수 있을 것이다.

추가하자면, 모든 management commands 는 다음과 같은 default option을 받을 수도 있다.
--verbosity
--traceback.

아래는 번역 중