오늘의 학습 키워드
- 포켓몬과 사람이 서로 매치되었을 때 텍스트로 그사람의 이름이 뜨기
- git허브에 대해
[1] 어제는 매치가 실패했을때 게임 가운대에 실패라고 뜨고 그 실패 텍스트를 버튼으로 바꿔서 누르면 게임이 지속되게 만들었었는데 그 버튼 부분 때문에 게임이 원활하게 돌아가지 않아서 이름 텍스트를 타이머 우측에 두는 김에 실패도 텍스트로 바꾸어 타이머 우측에 뜨게 바꾸었다.
public void Matched()
{
int num;
if(firstCard.idx == secondCard.idx +8 || firstCard.idx +8 == secondCard.idx)
{
if(firstCard.idx < secondCard.idx)
{
num = firstCard.idx;
}
else
{
num = secondCard.idx;
}
switch (num)
{
case 0:
nameTxt.text = "홍길동";
nameTxt.color = Color.black;
break;
case 1:
nameTxt.text = "홍길동";
nameTxt.color = Color.black;
break;
case 2:
nameTxt.text = "홍길동";
nameTxt.color = Color.black;
break;
case 3:
nameTxt.text = "홍길동";
nameTxt.color = Color.black;
break;
case 4:
nameTxt.text = "홍길동";
nameTxt.color = Color.black;
break;
case 5:
nameTxt.text = "홍길동";
nameTxt.color = Color.black;
break;
case 6:
nameTxt.text = "홍길동";
nameTxt.color = Color.black;
break;
case 7:
nameTxt.text = "홍길동";
nameTxt.color = Color.black;
break;
}
사진을 index로 하여 순서를 번호로 매겨서 포켓몬과 사람이 매치가 되어야한다
그렇기때문에 총 사진은 16장이 되고 그 순서는 0~7이 사람, 8~15가 포켓몬이 된다 그리고 0과 8이 서로 닮은 매치 카드라고 한다. 그래서 first카드가 포켓몬이 나올 수도 있고 second카드가 포켓몬이 나올 수도 있으니 or을 사용하여 서로 +8이 되는 카드를 매치카드라고 if문을 만들었다.
첫번째로 뽑은 카드가 포켓몬일 수도 있으니 if문을 그 안에 만들어서 만약 서로 매치되고 첫번째로 뽑은 카드가 두번째로 뽑은 카드보다 idx가 작을 경우 idx를 첫번째 뽑은 카드로 지정한다. 그 idx를 받기 위한 num변수를 선언해주고,
그 반대일 경우 즉, 두번째로 뽑은 카드가 첫번째 카드보다 idx가 작을 경우 num의 idx를 두번째 카드로 지정한다.
이후 각 카드별로 주어진 idx값이 나오면 이름 텍스트가 나올 수 있게 switch문을 사용하여 각각의 이름 text와 색깔을 검정색으로 만들어주었다.
반대로 매치되지 않았을 때 원래 버튼 형태로 만들었던 실패 텍스트를 이름 텍스트들과 똑같이 버튼 기능을 없애고 텍스트 형태로 바꿨다. 물론 색깔은 실패했다는 것을 강조할 수 있도록 빨간색으로 바꾸어 주었다.
else
{
nameTxt.text = "실패";
nameTxt.color = Color.red;
}
[2] git 허브에 대해
팀프로젝트에 앞서서 앞으로 캠프 진행, 취업했을 때 적극적으로 사용하는 git 허브에 대해 오늘 자세히 가르쳐주셨다.
- git 은 무엇인가?
- git 허브 사용 방법
- 충돌 발생 원인/ 회피 방법
- git flow 전략
- git Convention
(1) VCS - Version Control System 버전 관리 시스템
(2) 저장소를 통해 문제 해결 진행 (Git)
a) 지역 저장소 : local repositori
b) 공용 저장소 : remote repositori
(3) Git을 통해 문제점 해결
a) 한번에 모든 내용을 다운받다 보니 구분이 불가능
ㄴ 메모지에 내용을 적어서 공유하여 문제 해결
b) 작업물이 겹치기 시작하며 문제 발생
ㄴ 공용 저장소를 늘려서 문제 해결
c) 팀 프로젝트를 하는데 본인이 이용하는 Branch만 이용하다 보니 개인 프로젝트가 됨
ㄴ 공용 저장소에 구조를 만들고 복제를 통해 하위 저장소에서 상위 저장소로 합치는 과정을 통해 문제 해결
(4) 용어 정리
a) Commit : Local repositori 에 메모
b) History : Commit 이 모여있는 장소
c) Push : Local 에서 Remote 로 이동시키는 작업
d) Pull : Remote 에서 Local 로 이동시키는 작업
e) Branch : 각각의 복제된 공용 저장소를 지칭
f) Merge : Branch 에서 Branch 로 정보를 이동
g) Amend : Commit 한 내용을 수정해서 작성
h) Undo : Commit 한 내용을 취소 (Changes로 복구)
i) Revert : Commit 한 내용을 취소하지만 Revert Commit 이라는 History를 기록함
j) Checkout : History 에서 원하는 Commit 부분을 선택하여 해당 작업 내용으로 돌아가기
(1) Git hub 사용 순서
a) 원격 레포지토리를 생성 (Create a New Repositori on your hard drive...)
ㄴ Name(이름 작성) / Local path(저장 위치 선택) / Git ignore (Unity 선택)
ㄴ Name (기존 프로젝트 이름) / Local path (기존 저장 위치 선택) -> 복제 안하고 작업 진행 가능
b) 레포지토리 등록 (Publish repositori)
c) 지역 저장소 확인 (Current repositori -> 우클릭 -> Show in Explorer -> 저장 위치 확인)
d) 메모하기 (Changes -> 선택 -> Summary 작성 -> Commit to @@ -> History에서 확인 가능)
e) Push 하기 (Push origin 클릭 -> 원격 저장소로 내용 전달)
(2) Unity 폴더 구조
a) Assets (중요!)
b) Packages (중요!)
c) ProjectSettings (중요!)
d) Library, Logs, UserSettings (불필요 -> 삭제해도 됨)
(3) Git ignore
a) 무시할 파일을 적용
b) .gitignore 메모장에서 공유하고 싶지 않은 내용을 추가할 경우 git에 공유하지 않음
(4) Git에서 팀원 추가 방법
a) Git 에서 Repositori 선택
b) 상단 Settings 선택
c) Add people 선택 후 추가할 유저의 E-mail 주소를 입력하여 팀원 추가 가능
(5) Branch 만드는 방법
a) Current branch 클릭
b) New branch 클릭 후 이름 작성 및 복제할 Branch 선택
c) Publish branch 클릭하여 공유
(6) Changes 관리 방법
a) Discard changes : 수정 작업 삭제
b) Stash changes : 수정 작업 임시 저장 (Summary 위에 Stashed Changes 에 수정 작업 내용 생성)
c) Restore : Stashed Changes 에서 Changes 로 복구
(7) Merge 작업 방법
a) Merge 를 시킬 Branch 선택
b) Choose a branch to merge into @@ 를 클릭
c) Merge 를 받을 Branch 선택
d) Create a merge commit 을 클릭
※ 주의 사항
Merge 를 하기 전에 부모 Branch 로 이동해서 변경 점 확인
변경 점이 있다면 자신의 Branch 로 돌아와 부모 Branch 를 Merge
이 작업이 끝나면 부모 Branch 로 다시 Merge해야 안전함
(1) 충돌이 나는 경우
a) 같은 스크립트에서 같은 줄 내용을 수정 시 무조건 충돌
b) 아예 동일한 내용을 수정 시 무조건 충돌 (역할 분담을 확실하게 해서 겹치지 않도록 해야 함)
c) Scene 을 여러 명이 수정하는 경우 충돌 (파일 자체의 변경이라 복구 불가 / 한 가지 작업을 선택)
(2)대규칙
ㄴ 하나의 파일을 여러 명이 동시에 작업하지 말 것
(1) Git Flow 전략의 다양성


(2) Git Flow 전략 구상 단계
ㄴ 팀 프로젝트를 시작하기 전에 팀원들과의 합의 후에 정해서 진행하는 것이 맞음
(1) Git Convention 규칙을 사용하는 이유
ㄴ 팀 내에 누가 보더라도 어떤 부분이 변경되었는지 확인하기 쉽게 하기 위함
ㄴ 일을 효율적으로 진행하기 유리함

오늘의 회고
드디어 최종적으로 미니 프로젝트가 어느정도 완성이 된거같다.
3일동안 다들 열심히하고 안써본 것도 적극적으로 활용하려고 하고 그 모습들을 보면서 나 자신도 많이 배웠던 것 같다. 팀원 중에 어느 분들은 이미 현업에서 일을 하다가 오신 분들도 있어서 그 분들에게 많이 배우고 앞으로 어떻게 나가야 할 지 알게 된 것 같다.
내일 오후에 완성된 프로젝트 제출하고 금요일날 발표가 있을 예정이다.
마무리까지 화이팅!