CodeLog

• 프로젝트의 코드와 데이터의 백업입니다.
• 팀 맴버와 프로젝트내 파일 공유를 위한 도구입니다.
• 시간이 지남에 따라 어떻게 진화했는지 확인할 수 있는 타임 머신입니다.
• QA수단이며 파일 변경 사항을 제출하면 변경 사항을 혹인할 수 있는 귀중한 기회입니다.

• 컴퓨터에 로컬로 보관하거나 어딘가에 중앙 집중식 서버에 보관할 수 있습니다.

• 모든 전문 프로젝트는 버전 컨트롤을 사용한다.
• 모든 아마추어 프로젝트도 버전 컨트롤이 필요합니다.

• 일회용 코드 외에는 없이 할 생각하면 안됩니다.

• 버전 컨트롤을 위한 소프트웨어는 많습니다.
• Git과 Perforce 등 Unreal Engine을 위한 많은 좋은 버전컨트롤이 존재합니다.

1. 적절한 단위로 나누었는지 확인한다.
2. 제목은 잘지었는지 확인한다.
3. 메시지는 충분히 설명하고 있는지 확인한다.

1. 더이상 작업할 내용이 없는지 확인한다.
2. 적절한 단위로 나눠져 있는지 확인한다.
3. request제목이 적절한지 확인한다.
4. 메세지가 정확한지 확인한다.

좋은 git 커밋 메시지를 작성하기 위한 7가지 약속 (번역)

1. 제목과 본문을 빈 행으로 구분합니다.
2. 제목을 50글자 내로 제한합니다.
3. 제목 첫 글자는 대문자로 작성합니다.
4. 제목 끝에 마침표 넣지 않습니다.
5. 제목은 명령문으로 사용하며 과거형을 사용하지 않습니다.
6. 본문의 각 행은 72글자 내로 제한합니다.
7. 어떻게 보다는 무엇과 왜를 설명합니다.

정해진 방법은 없지만, 커밋을 자주 해야하는 질문들에 대해서 받은 내용입니다.

1. 어떤 기능에 대한 테스트가 끝났을 때, 보통 한 시간에 두 번 정도. 다섯번은 너무 많습니다.
2. 기능에 기반해서 커밋을 해야지 시간을 정해서 커밋을 하면 안됩니다. 새로운 기능을 추가했을 때 기능이 커밋할 만 하거나, 작동하는 메소드를 추가했거나, 글씨를 수정했거나, 잘못된 파일 들여쓰기를 수정했거나 등등일 때 커밋해야 합니다. 커밋이 의미가 있다면 작은 것을 커밋하는 것은 전혀 잘못된점이 아닙니다. 의미 없는 커밋은 히스토리로 이슈를 추적하는데 있어서 읽기 어렵게 합니다.
3. 새로운 테스트 케이스를 추가할 때, 테스트가 통과됐을 때, 변수 이름을 변경했을 때, 메소드를 삭제했을 때, 상태를 변경했을 때 등… 사실 커밋한 대상의 중요성은 중요하지 않습니다.

1. 작성할 이슈를 선택한다.
2. branch를 따 작업한다.
3. pull request후 종료한다. 왜 풀리퀘스트를 이용해서 브런치를 관리해야 하는가? 더럽지 않게 하기 위해서이다.

브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow입니다. 브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 합니다. 즉, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 말합니다.

브랜치 전략이 없을 때, 다음과 같은 질문이 생길 수 있습니다.

• 어떤 브랜치가 최신 브랜치인가?
• 어떤 브랜치를 끌어와서 개발을 시작해야 하나?
• 어디에 Push를 보내야 하나?
• 핫픽스를 해야하는데 어떤 브랜치를 기준으로 수정해야하나?
• 배포 버전은 어떤 걸 골라야하지?

Git-flow 브랜치 구조

보통 master와 develop가 많이 사용되며, 정상적인 프로젝트를 진행하기 위해서는 둘 모두를 운용해야 합니다.feature, release, hotfix branch는 사용하지 않는다면 지우더라도 오류가 발생하지 않기 때문에 깔끔한 프로젝트 진행을 원한다면 지워뒀다가 해당 가지를 활용해야 할 상황에 만들어도 괜찮습니다.

• 신규 기능 개발시, 개발자는 develop 브랜치로부터 본인이 신규 개발할 기능을 위한 feature 브랜치를 생성합니다. feature 브랜치에서 기능을 완성하면 develop 브랜치에 merge를 진행하게 됩니다.
• 라이브 서버로 배포시, feature 브랜치들이 모두 develop 브랜치에 merge 되었다면 QA를 위해 release 브랜치를 생성합니다. release 브랜치를 통해 오류가 확인된다면 release 브랜치 내에서 수정을 진행합니다. QA와 테스트를 모두 통과했다면, 배포를 위해 release 브랜치를 master 브랜치 쪽으로 merge하며, 만일 release 브랜치 내부에서 오류 수정이 진행되었을 경우 동기화를 위해 develop 브랜치 쪽에도 merge를 진행합니다.
• 배포 후 관리시 라이브 서버에서 버그가 발생된다면, hotfix 브랜치를 생성하여 버그 픽스를 진행합니다. 그리고 종료된 버그 픽스를 master와 develop 양 쪽에 merge하여 동기화 시킵니다.

1개월 이상의 긴 호흡으로 개발하여 주기적으로 배포, QA 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면 git-flow가 적합합니다.

Git flow가 좋은 방식이지만 GitHub에 적용하기에는 복잡하다는 판단에 따라 만들어진 새로운 깃 관리 방식입니다. 자동화 개념이 들어가 있다라는 큰 특징이 존재하며 만일 자동화가 작용되어 있지 않은 곳에서만 수동으로 진행할 수 있습니다.

수시로 릴리즈 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀이라면 github-flow 와 같은 간단한 work-flow가 적합합니다.

• 기본적으로 master branch에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 pull request 기능을 사용하도록 권장합니다.

GitHub-Flow의 특징으로

1. release branch가 명확하게 구분되지 않은 시스템에서의 사용이 유용합니다.
2. GitHub 자체의 서브스 특성상 배포의 개념이 없는 시스템으로 되어있기 때문에 이 flow가 유용합니다.
3. 웹 서비스들에 배포의 개념이 없어지고 있는 추세이기 때문에 앞으로도 Git flow에 비해 사용하기에 더 수월할 것 입니다.
4. hotfix와 가장 작은 기능을 구분하지 않습니다. 모든 구분사항들도 결국 개발자가 전부 수정하는 일들 중 하나이기 때문입니다. 대신 구분하는 것은 우선 순위가 어떤 것이 더 높은지에 대한 것 입니다.

• 브랜치 생성시, Github-flow 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 시작합니다. 단, 이때 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요합니다.
  • master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치입니다. 이 브랜치에 대해서는 엄격한 role과 함께 사용합니다.
  • 새로운 브랜치는 항상 master 브랜치에서 만듭니다.
  • Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않습니다.
  • 그렇지만, 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성하도록 합니다.
• 개발 & 커밋 & 푸쉬시, 개발을 진행하면서 커밋을 남깁니다. 이때도 브랜치와 같이 커밋 메세지에 의존해야 하기 때문에, 커밋 메세지를 최대한 상세하게 적어주는 것이 중요합니다.
  • 커밋메시지를 명확하게 작성합니다.
  • 원격지 브랜치로 수시로 push합니다.
  • Git-flow와 상반되는 방식입니다.
  • 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해줍니다.
  • 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해줍니다.
• PR(Pull Request) 생성시, 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성합니다.
  • pull request는 코드 리뷰를 도와주는 시스템입니다.
  • 이것을 이용해 자신의 코드를 공유하고, 리뷰받습니다.
  • merge 준비가 완료되었다면 master 브랜치로 반영을 요구합니다.
• 리뷰 & 토의시, Pull-Request가 master 브랜치 쪽에 합쳐진다면 곧장 라이브 서버에 배포되는 것과 다름 없으므로, 상세한 리뷰와 토의가 이루어져야 합니다.
• 테스트시, 리뷰와 토의가 끝났다면 해당 내용을 라이브 서버(혹은 테스트 환경)에 배포해봅니다. 배포시 문제가 발생한다면 곧장 master 브랜치의 내용을 다시 배포하여 초기화 시킵니다.
• 최종 Merge시, 라이브 서버(혹은 테스트 환경)에 배포했음에도 문제가 발견되지 않았다면 그대로 master 브랜치에 푸시를 하고, 즉시 배포를 진행합니다. 대부분의 Github-flow 에선 master 브랜치를 최신 브랜치라고 가정하기 때문에 배포 자동화 도구를 이용해서 Merge 즉시 배포를 시킵니다. master로 merge되고 push 되었을 때는, 즉시 배포되어야합니다.
  • GitHub-flow의 핵심입니다.
  • master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓습니다. (CI / CD)

“git remote”커맨드는 변경사항을 동기화 하는 시스템의 한 부분입니다. git fetch, git push, git pull과 함께 사용됩니다. 이러한 명령에는 모두 해당 링크에서 탐색할 수 있는 자체 동기화 책임이 있습니다.

• Git은 파일 및 폴더의 대무자 소문자를 구분하지 않습니다.

& git init   
& git remote add origin "https://github.com/id/id.github.io"   
& git pull origin master   

& git remote rename origin test   
& git remote -v   
& git remote rename test origin

& git add .   
& git commit -m "message"   
& git status   
& git push origin   

& git help   
& git help remote   

& add file_name.xxx

커밋에 단일 파일의 변경사항을 포함합니다. 상관 없는 여러개의 파일을 변경한 다음 commit할 경우, 직접 변경한 파일을 지정하여 커밋할 수 있습니다.

& git reset HEAD(16진수 숫자)~삭제갯수
& git log 

HEAD부터 삭제갯수만큼 commit을 삭제합니다.

& git branch BranchTest   
& git branch   
& git checkout BranchTest   

BranchTest 브런치를 만들고, BranchTest로 이동한다.

& git checkout master   
& git branch --delete BranchTest   

마스터 브런치로 돌아간 후, BranchTest를 삭제한다.

& git branch test   
& git checkout test   
... work ...   
& git checkout master   
& git merge test   

& git branch -d test   

test 브런치를 삭제합니다.

& git branch issue2   
& git branch issue3   
& git checkout issue2   
... work ...   

Master branch, 제품으로 출시될 수 있는 브랜치입니다.

Develop branch, 기능 개발을 위한 브랜치들을 병합하기 위해 사용하는 브랜치 입니다.

Feature branch, 기능을 개발하는 브랜치 입니다.

Release branch, 이번 출시 버전을 준비하는 브랜치 입니다.

Hotfix branch, 출시 버전에서 발생한 버그를 수정하는 브랜치입니다.

& git log   
! type q exit it.   
& git log --graph --decorate --oneline   

& git branch issue2   
& git branch issue3   
... work ...   
& git merge issue2   
& git checkout issue3   
& git rebase master   
& git rebase --continue   

locally와 remotely에서 branch를 지우는 방법입니다.

& git branch -d branch_name   

로컬에서 브런치를 지웁니다.

& git push remote_name --delete branch_name   

원격에서 브런치를 지웁니다. (Git v.1.7.0 이상부터)

git ignore sample

프로젝트 작업시 로컬 환경의 정보나 빌드 정보등 원격 저장소에 관리하지 말아야되는 파일들에 대해서 지정하여 원격 저장소에 실수로 올라가지 않도록 관리하는 파일입니다. .gitignore는 프로젝트 파일의 최상단에 위치합니다.

Git Tools - Submodules

기존 프로젝트의 일부를 서브모듈로 만들기 위해서는 다음과 같은 방법을 따릅니다.

& git submodule deinit -f

먼저 명령어를 통해서 해당 모듈을 deinit 해줍니다.

& git submodule deinit -f test_app

그 다음 .git/modules 폴더에 들어가서 해당 폴더를 삭제합니다.

& rm -rf .git/modules/test_app

마지막으로 git에서 해당 폴더를 제거해주면 됩니다.

& git rm -f test_app

TortoiseSVN DOC

• 업데이트시 변경한 파일들을 덮어씌우므로 조심해서 해야합니다.
• 커밋시 변경사항을 변경한 내용을 명확히 확인한 다음 커밋해야 합니다.
  • 커밋하지 않고 업데이트하면 변경내용을 잃어버리게 됩니다.
  • 예를 들어 MainLevel은 아트팀에서 관리합니다. 메인 레벨을 변경하면 아트팀의 작업내역과 충돌하게 됩니다.
• 추적하지 않는 파일을 확인해서 커밋해야합니다.
  • 언리얼엔진의 블루프린트의 부모 클래스 누락하고 커밋하면, 블루프린트가 깨지게 됩니다.
• 커밋시 깨졌을 경우 정리 명령어를 실행하라고 표시됩니다. TortoiseSVN에서 정리명령을 실행할 수 있습니다.

SVN Revision 되돌리는 법

커밋을 실수해도 당황하지 말고 되돌려서 사용하도록 합니다. 커밋을 되돌릴 수 있기만 해도 어지간한 문제는 해결 할 수 있습니다.

언리얼 엔진에서 SVN 오류를 피하기 위한 전략

1. 저장하지 않는다. 자동 저장 기능을 사용하지 않고 직접 변경한 내역만 저장하도록 한다.
   • 이때 연관된 래퍼런스가 깨질 수 있다.
2. 해당 하는 부분만 변경되었는지 확인하기 위해서, 엔진을 자주 껐다 킵니다.
3. 기존 프로젝트를 끈 후, 변경하지 않은 내역에 대해 되돌리기를 수행합니다. 그리고 다시 테스트합니다.

실수 모음

블루프린트 디폴트로 리셋, 후 커밋에서 제외하면 인스턴스의 위치값들이 기본값으로 변경됩니다.

• 이는 제가 변경사항을 블루프린트 디폴트로 리셋한 적이 있을 때마다 나타났으므로, 다른 BP의 변경사항을 건든 것으로 생각됩니다.