Giters

ttamna / github-best-practice

Links to GitHub best practice articles/blogs etc.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

GIT, GITHUB RULE

효율적인 협업을 위해서, 깃과 깃헙 사용 규칙을 정해 놓읍시다.

Repository organisation

  • One conceptual group per repository (the conceptual group size/scope may vary between projects)

  • Define codeowners for each repository code owner

  • Don't commit things that can be regenerated from the code

  • Use pre-commit hooks for code-checking code quality

  • Use continuous integration where appropriate (e.g. TravisCI)

  • Use code quality integration where appropriatecode quality

  • Use test coverage integration where appropriate (e.g. codecov.io)

  • Don't change the published history

  • Avoid large binary files, but if you can't avoid it, use git-lfs to store them

  • align package version

  • lock package version

  • archive dead repositories

Day-to-day working

  • git pull before you work; git push when you're done
  • Review code before you check it in
  • Make small commits that implement a single logical change and can be described in a simple statement
  • Commit early and often
  • Write your commit messages as imperative statements * see this
  • Use SSH keys to log in if possible

Workflow

제품 특성에 따라 다른 전략이 필요할 수 있다

  • Use the workflow that is customary in your group

Release가 명확한 제품

  • 업데이트가 바로 반영될 수 없는 제품
  • 프로그램이 클라이언트 측에서 동작
  • git flow

Release가 명확하지 않은 서비스

  • 팀 규모가 크거나, 수시로 업데이트가 되고 바로바로 반영되는 서비스
  • 프로그램이 서버 측에서 동작
  • github flow

Git flow

git-flow

팀 규모가 작거나, 릴리즈가 없는 서비스에 적합한 전략으로 Github flow에 비해 단순하다

Git flow 특징

  • 5가지 종류의 브랜치로 구성된다
    • master: 제품으로 출시될 수 있는 브랜치
    • develop: 다음 출시 버전을 개발하는 브랜치
    • feature: 기능을 개발하는 브랜치
    • release: 이번 출시 버전을 준비하는 브랜치
    • hotfix: 출시 버전에서 발생한 버그를 수정하는 브랜치

Git flow 프로세스

Github flow (Forking Worklfow)

github-flow

Release가 있는 제품에 적합한 전략으로, 명확한 구조 위에서 작업한다

Github flow 특징

  • Upstream Repository, Origin Repository, Local Repository 로 구성된다

    • Upstream Repository는 다른 개발자들과 공유하는 원격 저장소로, 최신 정보를 유지하고, 배포에 사용된다
    • Origin Repository는 Upstream Repository로부터 복사한 원격 저장소로, 개인이 사용한다
    • Local Repository는 내 컴퓨터에 있는 저장소로, 개발할때 사용한다

  • 아주 큰 규모의 분산된 팀에서도 안전하게 협업하기에 좋은 협업 방법

  • 오픈소스 프로젝트에서 많이 사용하는 방식

  • CI가 필수적이다

  • master branch에만 정해진 규칙이 있다

  • master branch는 안정 버전을 유지해야 하므로, merge하기 전에 충분히 테스트해야 한다

Github flow 프로세스

  • Upstream Repository로부터 fork (Origin Repository가 생긴다)

  • Origin Repository로부터 clone (Local Repository에서 개발할 준비가 된다)

  • Branch 생성

    • github flow에서 Local Repository, Origin Repository의 branch 생성은 자유롭다

    • 이름은 잘 지어야 한다. 브랜치 이름을 보면, 어떤 작업인지 알 수 있도록

    • branch는 항상 master branch에서 만든다

      git checkout -b <new_branch> master

  • 자주 push 해 자신이 무엇을 하고 있는지 동료들과 공유한다

  • 피드백이나 도움이 필요할때, 그리고 머징 준비가 완료됐을때는 pull request를 생성한다

    • 제목에 '도움이 필요해요', '검토좀 해주세요', '머지해도 됩니다' 로 구분한다
    • @mention으로 쉽게 다른 사람에게 검토를 요청할 수도 있다.
    • pull request는 브랜치를 두고 토론하는 것으로, 브랜치 히스토리가 업데이트되면, 그 최신정보도 자동으로 포함된다

  • 기능에 대한 리뷰와 테스트가 끝난후 master로 머지한다

    • 테스트는 로컬에서 하는 것이 아니라 브랜치를 push하고 Jenkins로 테스트한다
    • push하면 자동으로 pull request가 닫힌다(?todo: 무슨내용인지 확인필요)

  • 일단 master에 merge 하면 바로 deploy한다.

    • hubot으로 deploy한다. github은 최근 Jenkins + Hubot + Github을 묶은 Janky를 공개했다.

상세

Separate

Branch

  • protect the main branches from direct commits gitflow workflow, branch protection
  • protect your project (master branch)
  • for every new feature, start a new branch named after that feature
  • once the branch is stable, create a pull request

Commit

Pull Request

  • always pull the latest updates (for avoid resolving unnecessary merge conflicts)

  • keep history consistent (squash

  • rebase your branches periodically

  • choose the right developers for the job

  • the more approvals, the better

  • review other's code independently

Useful .gitconfig aliases

alias.lol=log --graph --decorate --pretty=oneline --abbrev-commit
alias.lola=log --graph --decorate --pretty=oneline --abbrev-commit --all
alias.hist = log --graph --pretty=format:'%h %ad | %s%d [%an]' --date=short

create a meaningful .gitignore file for your projectsref

with Jira

  • make time tracking easier

Integration

Code Quality

CI

Deploy

Jira

TODO: JIRA

Useful hints

Useful quotes

I have certain mantras that I use to guide my programming. They generally revolve around this theme: "Thinking is hard, and I'm not very good at it; every block of code should be simple and obvious, because if it makes me think, I'll probably screw it up and break something." * Remy Porter

Oh, shit

  • Oh, shit, git!: http://ohshitgit.com/
  • rewrite; don't rage
    • 실수로 브랜치를 삭제하거나 잘못 머지했을때, 멘탈이 부서지고 강제로 push할수 있는데 그러지 말자
    • git undo 기능이 있다. 침착하자.
    • branch를 하나 더 만드는 것을 두려워하지 말자(실수했으면 지우고 브랜치를 새로 만들어서 작업하자)
    • remote 저장소의 내용이 잘못됐으면, local에서 바로잡고, 강제로 push 할수 있다(동료에겐 다시 pull 받으라고 할 수 있다)

Use the Source!

About

Links to GitHub best practice articles/blogs etc.

License:MIT License