다음 주 미니 프로젝트가 시작되기 전에 점검차 스터디 팀원들과 github협업 연습을 했다.

아직 깃허브로 협업하는 과정이 익숙하지 않아 명령어로 진행해야 하는 Terminal을 사용하지 않고 비교적 직관적이고 사용이 쉬운 소스 트리로 진행하였다. 완벽한 깃허브 사용이라고 할 수는 없었지만, 그래도 큰 틀을 이해할 수 있는 연습이었다. 앞으로를 위해 일단 전반적인 협업 연습 과정을 정리해 보자! 

1. 이슈 생성 : 프로젝트 주제에 맞게 이슈를 생성한다. (예 - 제가 ~~기능을 추가하겠습니다!)

2. 각자 소스트리에서 내 담당 브랜치를 만들고, 파일을 commit(commit msg에 이슈 번호 추가) - push(dev 브랜치로) 해준다. 

3. github 프로젝트 페이지로 이동해 PR(Pull Requests) 날려준다 ! 

4. 반영 내용이 괜찮으면 confirm! - Merge를 진행한다.

5. 머지를 하는 과정에서 다음과 같이 충돌이 일어났다면 Resolve coflicts를 클릭한다.

6. 충돌이 일어난 부분을 확인하고 수정해 준다.

7. 머지에 성공하면 해결된 이슈를 close 해주고, 머지가 끝난 브랜치도 삭제해 줌으로써 훗날 헷갈리지 않도록 정리를 해준다! :) 

8. dev에 머지 충돌을 해결한 모든 브랜치 병합을 완료했다면, 배포용인 main 브랜치로 push 해주면 완료! 

우리 10조 너무 좋았는데 다음주에 헤어질 생각 하니까 너무 아쉽다 ㅠ-ㅠ 그래도 앞으로 저녁 9시 이후 추가 공부 시간에 같이 하기로 ! 

모두들 한 주 고생 많으셨습니다 !! : ) ( 아! 그리고 우리조는 아니지만 우리조 같은 현빈님 민승님도 고생하셨습니다 ㅎㅎ) 

[오늘의 회고]

1. 어려웠던 부분 : 열거 타입을 공부하면서 나오는 개념들 (예를 들면 소스 파일, 매소드, 클래스, 스레드 등)을 다시 한번 다잡아야 겠다. 역시나 이론은 이해가 되는데 연습문제를 해결하려 하면 풀이가 쉽지 않다. 기술매니저님이 알고리즘 풀이는 수능처럼 많이 해서 익숙해지는 법 밖에 없고 또 하는 만큼 실력이 늘거라고 하셨으니까 그말을 믿고 꾸준히 해야겠다. 

2. 느낀 점 : 팀원이 정말 중요하다는 것을 다시한번 느꼈다. 일주일이었지만 다른조 보다 열심히 공부하는 팀원들 덕분에 나도 동기부여가 되서 열심히 할 수 있었던 것 같다. 이제 다음주면 팀원이 바뀐다는게 너무 아쉽다 ㅠㅠ ! 그리고 오늘 git 강의를 듣고 팀원들과 같이 연습해 보았는데, 서로 모르는 부분을 가르쳐주고 배울 수 있던 부분이 너무 인상적이었다. 앞으로 남은 기간도 끝까지 같이 으쌰으쌰 하기를 !!

3. 새로 알게 된 내용 : 열거 타입의 개념을 알게되었다. 그리고 오늘 스터디 팀원들과 소스트리를 이용한 github 협업 연습을 해보았다. b반이 친해지기 위한 방법이라는 주제로 일단 텍스트 파일로 각자 브랜치를 만들고 머지해보고 또 일부러 머지 컨플릭트를 만들어서 해결해보는 연습을 했다. 확실히 실전 연습을 하니 이해가 훨씬 잘 되었던 것 같다. 

4. 셀프칭찬 : 스냅카메라를 통해 팀원들에게 웃음을 선사했다. ㅎㅎㅎ 뿌듯하다 너무 ㅎㅎㅎ ! 다들 앞으로도 웃을일이 많은 99일이 되었으면 좋겠다 ! 분위기가 다운될 땐 팀원들을 위해 기꺼이 필터를 사용해서 웃겨드려야 겠다 !! 

5. 내일 할 일 : 열심히 쉬고 회복하기 ! 

[오늘 공부한 부분]

1. Java 열거 타입

2. Github 협업 연습

https://leejincha.tistory.com/84

[오늘 공부한 부분]

1. Java 열거 타입

1. 열거 타입

• 열거 타입(enumeration type) : 한정된 값만을 갖는 타입
• 열거 상수(enumeration constant) : 열거 타입은 한정된 값인 열거 상수 중에서 하나의 상수를 저장하는 타입이다.

• 여기서 Week가 열거 타입이고, MONDAY ~ SUNDAY는 열거 상수이다.
• Week로 다음과 같이 변수를 선언할 수 있다 : Week today;  
• today 변수에 저장할 수 있는 건 Week에 선언된 7개의 열거 상수 중 하나이다 : today = Week.FRIDAY;

2. 열거 타입 선언

• 먼저 열거 타입의 이름을 정하고 해당 이름으로 소스파일(.java)를 생성한다.
• 열거 타입의 이름은 관례적으로 첫 글자를 대문자로 하고 나머지는 소문자로 구성한다. : Week.java
• 만약 여러 단어로 구성된 이름이라면 각 단어의 첫 글자는 대문자로 하는 것이 관례 이다. : ProductKind.java
• 열거 상수는 관례적으로 모두 대문자로 작성한다. : MONDAY ... SUNDAY
• 만약 열거 상수가 여러 단어로 구성될 경우 단어 사이를 (_)로 연결한다. : LOGIN_SUCCESS

public enum 열거타입이름 {열거 상수1, 열거 상수2, ...}

3. 열거 타입 변수

• 아래와 같이 열거 타입 변수를 선언할 수 있다.
• 열거 타입 변수를 선언했다면, 열거 상수를 '열거타입.열거상수' 형태로 저장할 수 있다.
• 열거 타입 변수도 null 값을 저장할 수 있다.

Week today; // 열거 타입 변수 ㅅ선언

Week today = Week.SUNDAY; //다음과 같이 열거 상수 저장

Week birthday = null; //열거 타입 역시 참조 타입이기 때문에 null값을 저장할 수 있다.

• 열거 타입 변수 today는 스택 영역에 저장된다.
• today에 저장되는 값은 Week.SUNDAY 열거 상수가 참조하는 객체의 번지이다.
• 따라서 열거 상수 Week.SUNDAY와 변수 today는 서로 같은 Week 객체를 참조하게 된다.
• 따라서 today == Week.SUNDAY (true)

※ 열거 타입 Week를 이용하려면 날짜 정보가 필요하다.

이때 Calendar 클래스를 사용한다

Calendar now = Calendar.getInstance();

Calendar 객체를 얻었다면 get()메소드를 이용해서 다음과 같이 얻을 수 있다.

int year = now.get(Calendar.YEAR); //연
int month = now.get(Calendar.MONTH)+1; // 월
int day = now.get(Calendar.DAY_OF_MONTH); //일
int week = now.get(Calendar.DAY_OF_WEEK); //요일
int hour = now.get(Calendar.HOUR);//시
int minute = now.get(Calendar.MINUTE); //분
int second = now.get(Calendar.SECOND); //초

Calendar를 사용하기 위해서는 import문이 필요하다 : import java.util.Calendar; 

※ 열거 타입과 열거 상수 예시

• Calendar를 사용하기 위해 인텔리제이가 자동으로 import해주었다.
• 열거 타입 변수를 선언하고, Calendar 클래스를 통해 오늘 요일 값을 받는다.

• 열거 변수 today에 열거 상수를 대입해 준다.

• 실행해 보면, 이 글을 작성하는 오늘은 토요일이기 때문에, 다음과 같은 값을 얻을 수 있다.

1. git은 현업에서 실제로 어떻게 쓰일까 ?

① 누가 이 작업할 거에요? - Issue 할당

② 각자 공간에서 작업하기 - Branch 

③ 작업 내용 합치기 - Merge(병합) / Merge conflict 해결

+ (경우에 따라) 작업한 내용을 리뷰하고 최종적으로 프로젝트에 반영한다. - PR 후 merge

2. Issue 할당

• 프로젝트에서 issue(이슈) : 프로젝트에서 해결해야하는 문제
  • 버그(프로그램이 원하는 대로 동작하지 않는 것)를 신고 (Bug report, 버그 리포트)
  • 기능 추가 등의 프로젝트 개선 제안 (enhancement)
  • 위 문제들을 해결하기 위한 작업단위
• issue 생성하는 방법 ( 각 항목을 아래처럼 적어주기 )
  • 제목과 상세 내용은 협업하는 사람도 잘 알아볼 수있도록
  • Assigness(담당자) : 이 이슈를 작업하거나 연관된 사람
  • Labels: 이 issue 가 어떤 건지 분류. Github이 만들어준 기본 라벨을 사용할 수도 있고, 내가 직접 만들어줄 수도 있다. 
  • 내용을 적은 후에 하단 초록색 버튼 Submit new issue 클릭!

3. 각자 공간에서 작업하기 - Branch

• 각 작업 브랜치에서 작업할 때는 다른 브랜치의 영향을 받지 않고 독립적으로 작업할 수 있다.
• 작업 목적에 따라 branch 를 만들어서 관련된 작업만 하고, 나중에 하나로 Merge하게 된다.
• Merge 하는 과정에서 같은 파일이 동일한 부분이 수정된 게 발견되면 Merge conflict(병합 충돌) 이 발생한다.

① 브랜치 생성하기:

1. 왼쪽 히스토리 탭을 선택하고 - 마지막 commit 에서 우클릭 한 후 브랜치 를 선택!

2. 새 브랜치 : 브랜치 이름을 내가 잘 관리할 수 있게 적어주기. ex) `feature/이슈번호_관리쉬운이름` 형식 (feature 는 기능 개발하는 브랜치에 관행적으로 붙여주는 이름)
3. 정보를 입력한 후 '브랜치 생성' 버튼 클릭!

• 왼쪽 브랜치 탭 : feature 밑에 3_jjigae 항목이 생긴걸 확인할 수 있다. sourcetree 에서는 브랜치명 안에 / 를 적어주면 마치 폴더처럼 보여준다. (create branch - feature/3_jjigae)
• 해당 commit 에 붙어있는 파란색 이름표는 브랜치명이다. 해당 브랜치의 최신 commit 에 이름표를 붙여 준다.
• 현재 작업하는 브랜치를 선택하는 것을 체크아웃(checkout) 이라고 한다. sourcetree 에서는 체크아웃된 브랜치, 즉 현재 작업 브랜치를 브랜치명 왼쪽 에 O 표시가 되어있다. 체크아웃된 브랜치에만 commit이 반영된다.

※ 각 이름표는 아래와 같은 뜻을 가지고 있다.

• main : 로컬 repo의 main 브랜치
• feature/3_jjigae : 로컬 repo의 feature/3_jjigae 브랜치
• origin/main : origin(연결시켜준 원격 repo)의 main 브랜치
• origin/HEAD : 현재 작업중인 commit. origin(연결시켜준 원격 repo)의 최신 commit

② 브랜치 commit하기

③ 브랜치 삭제하기

• 삭제할 브랜치는 체크아웃(현재 작업 중인) 브랜치가 아니어야 한다.
• 다른 브랜치 이름을 더블 클릭해서 다른 브랜치로 체크아웃한 후 진행하기! 
• 삭제할 브랜치 선택 - 우클릭 - 해당 브랜치명 삭제 - 강제 삭제 옵션 선택 - 확인

4. 작업 내용 합치기 - Merge(병합) 

• 브랜치의 작업 내역 commit 들을 다른 branch 로 반영(합치기)는 것을 Merge(머지, 병합)라고 한다.
• 기본적으로 branch 단위로 merge 하게 된다.
• 개발할 때는 기준이 되는 기본 브랜치를 정해놓고 다른 브랜치들을 기본 브랜치에 merge한다. (주로 distribution용, development용으로 병합)
• 브랜치명은 규칙을 가지고 잘 이름 지으면 프로젝트 관리가 쉽다.
• 작업이 완료되면 작업한 브랜치는 보통 삭제해 줌으로써 나중에 브랜치 설정이 꼬이는 것을 방지할 수 있다.

① 브랜치 Merge 하기

• 커밋을 반영시킬 브랜치로 체크아웃
• 파일 수정이 필요한 경우 상단 오른쪽에 파인더에서 보기를 클릭하여 현재 체크아웃 된 브랜치 내부의의 정확한 파일을 수정하도록 한다.
• 머지할 부분을 클릭하고 소스트리 상단 merge(병합)을 클릭한다.
• 아래와 같이 체크리스트를 확인해 주고 병합한다.

② Merge conflict

• 에러를 안 내는 게 중요한게 아니라 버그(컴퓨터가 의도한 대로 동작하지 않는 것)를 고칠 수 있느냐 없느냐가 중요! 에러에 쫄지 말자
• 하나의 파일을 여러 브랜치에서 수정하고 하나의 branch에 merge 하려고 할 때 merge conflict(병합 충돌) 가 발생한다.
• 이럴 때 git 은 친절하게 이 충돌나는 내용 중에 어떤 내용을 반영하면 좋겠니? 하고 확인하는 메시지를 주고 자동으로 파일을 합친 다음에 충돌이 나는 부분을 아래처럼 보여준다.

• <<<<<<< 에서 >>>>>>> 까지가 충돌이 나는 부분이다. 변경된 내용 중 어떤 것을 브랜치에 반영할지 파악을 돕기 위해 정보를 알려주고 있다.
• 이 merge confilct 를 고치려면, 내가 원하는 대로 파일을 수정하고(어떤 내용을 반영할지 결정) <<<<<<< HEAD , ======= , >>>>>>> 충돌나는 브랜치명 또는 commmit 아이디 를 지우면 된다.
• 그러면 Git 이 해결되었구나! 하고 알아듣는다. =======를 기준으로 앞 부분 <<<<<<< HEAD 부분은 현재 브랜치, 즉 main 브랜치의 해당 파일의 내용을 보여준다.
• 즉, 현재 브랜치(main)의 파일 내용은 아래와 같다. 분홍색 부분이 다른 브랜치와 다른 부분을 보여준다.

• 그런 후에 이렇게 수정된 파일을 commit 하면 완료!
• 충돌을 해결하기 위해서는 반영할 내용만 남기고 지워주면 되는데, 새로운 추가사항은 병합 후 다시 새로운 커밋메시지로 업데이트 해주는 것 좋다. 이렇게 하는 것이 나중에 버그를 찾기도 쉽고 팀원들과 더 원활한 소통을 할 수 있게 해준다.
• 파일을 수정하고 나서 sourcetree 를 켜고 하단 commit 메시지 적는 창에 마우스 클릭하면 자동으로 커밋 메시지가 작성된다. 
• 자동으로 작성되는 commit 메시지 끝부분을 보면 어떤 파일이 conflict(충돌)났는지도 정보도 적혀있다.

5. 원격 repo 와 Branch

• tracking 한다는 것은 로컬 repo와 원격 repo의 특정 브랜치를 연결해주는 것
• 따로 설정을 해주지 않으면 기본적으로 로컬 repo의 브랜치명와 같게 원격 repo의 브랜치명이 생성되어 tracking된다.
• push와 pull 은 기본적으로 tracking(추적)되고 있는 브랜치를 기준으로 commit 내역을 반영한다.

[ 오시영 튜터님의 꿀팁 자료들 ]

구글링이 무엇인가요?

• 여러분이 모르는 것, 전 세계 사람들 다 모릅니다. 이럴 땐 필요한 건 구글! 구글에 검색한다고 해서 구글링(Googling) 이라고 합니다.
• 기술(도구 이름) + 단어 조합으로 하면 훨씬 더 좋은 검색 결과를 얻을 수 있어요. ( 예. sourcetree branch )
• 검색어 팁
  • 아래처럼 검색어를 조합해 입력해보세요!
  • 기술을 처음 배우고 싶을 때 : '기술이름' + 'tutorial' (예. git tutorial)
  • 기능을 찾을 때 : '기술이름' + 'how to' + '찾을 내용' (예. git how to merge )
  • 어떻게 사용하는지 예제를 보고 싶을 때 : '기술이름' + '내용' + 'example' (예. github flow example)
  • 원하는 사이트명 포함해 검색할 수도 있습니다. (예: stackoverflow git merge - stackoverflow 라는 사이트에서 검색)
• 검색 결과 중에, 좋은 자료 고르기
  • 좋은 자료를 찾으려면 경험치가 필요해요. 많이 검색해보면 자연스레 나만의 검색 노하우와 자료 판단하는 눈이 길러질 거에요.
  • 해결책뿐만 아니라 문제(에러)의 이유까지 적어두어서 내 문제와 같은지 판단할 수 있는 정보를 제공하는 글
  • stackoverflow - 개발 QnA 사이트입니다. 전 세계적으로 많이 쓰입니다. 질문과 답변, 댓글에 사용자들이 vote 할 수 있어요. 좋은 질문과 답변에는 vote 수가 높습니다.
  • 기술 공식 문서
• 신뢰할 수 있는 블로그(tech 회사의 기술 블로그, IT 전문 매거진) ex) 우하한형제들 기술 블로그

개발 공부를 더 잘하기 위한 방법

1. 내용이 쉽다 → 난이도 높이기

• 추가자료 읽어 보고 생각/실제로 해보기
•  나만의 실험 고안하기
• 에러를 일부러 내보고 해결하는 거 구글링해보기
• 그 과정에서 내가 깨달은 것 TIL 에 적어보기

2. 아 적절해요 좋은데요?

• 다양하게 시도해보기
• 그 과정에서 내가 깨달은 것 TIL 에 적어보기

3. 너무 어렵다, 집에 있어도 집에 가고 싶다! 🏠

• 난이도 낮추기
• 영상 보면서 천천히 시간 들여서 따라해보기
• 그 다음에 다시 시도해보기
• 내가 어려워했던 내용이 무엇인지 정리해보기
• 그 과정에서 내가 깨달은 것 TIL 에 적어보기

[오늘의 회고]

1. 어려웠던 부분 : 배열이 이렇게 어려웠던가... 오늘따라 뭔가 머리에 과부하가 오고 집중이 잘 되지 않았다. CS50 강의에서 봤던 부분이랑 연관된 부분이 많아서 그나마 이해를 할 수 있었던 것 같은데, 그래도 여전히 참조 타입에서 포인터 개념을 이해하하는 것은 머릿속으로 잘 그려지지 않는 것 같다.

2. 느낀 점 : 어제 공부했던 연습문제를 다시 한번 복습해봤다. 두번째 풀이 시도에서 역시나 또 해결하지 못했지만, 3번째 풀이 시도에서는 답안을 보지 않고 구현할 수 있었다. 구조적인 뇌가 아닌 나는 미련하지만 이렇게 일단 암기를 하고 후에 이해를 하는 과정으로 공부를 하는게 맞는 것 같다. 예전에 수학선생님이던 고모부께서 '수학은 암기과목이다' 라고 하셨던 말이 기억에 남는다. 일단 이해가 안되더라도 머리에 암기로 넣어보자. 그럼 어느 순간 이해되는 날이 오겠지 ! 

3. 새로 알게 된 내용 : String[ ]배열에서 참조값만 구분하는 메소드와 객체 자체를 구분하는 메소드 equals(), hashcode(), identityHashcode()를 알게 되었다. 나였더라면 궁금해하지 않고 넘겼을 부분을 스터디팀원분 덕분에 새롭게 배울 수 있었다.

스터디팀원분들 처럼 나에게도 당장 눈앞의 공부뿐만 아니라 더 멀리 보는 시야가 생기기를 !! 

4. 셀프칭찬 : 정말 정말 공부하기 싫은 날이었는데, 그래도 해냈다! 아침부터 어제 민승님이 추천해주신 프로그래머스 부지런히 깃헙이랑 연결하고 문제도 풀고, 코딩에 흥미를 잃지 않기위해 티스토리 블로그 html도 건드려 보면서 바꿔보고, 기술매니저님한테 용기 얻는 조언도 부탁해서 다시 마음도 다잡고. 잘했다 잘했어 

5. 내일 할 일 : chap05 연습문제 다시 풀어보기 + 나머지 부분(열거 타입) 공부 , TIL작성, git3 주차 강의, github 협업 연습

• 오늘 못들은 git 3주차 강의를 내일 오전에 끝내자 !!!
• 기술매니저님이 추천해주신 개발자 뉴이슈 사이트 : ( https://news.hada.io/ )
• 좋은 스타트업을 고르고 싶다면 ? 1. 잡플래닛 참고 2. 크래딧잡 참고 ( 1. 퇴사율이 30% 이상이면 거르자 2. 최근 퇴사율을 확인하자 3. JOB담 부분을 참고해서 분위기를 파악하자 4. 시니어가 많은지 체크하자) 
• 제로베이스 비전공자일수록 더 열심히 해야 그나마 전공자 혹은 경력자 발끝이라도 따라간다. 무조건 열심히 꾸준히, 흥미가 없어도 일단 꾸준히 하자.

[오늘 공부한 부분]

1. Java 참조 타입과 참조 변수 

2. Java 배열

+ programmers 4문제

+ 티스토리 블로그 html 수정하기

+ 어제 연습문제 복습

https://leejincha.tistory.com/80

https://leejincha.tistory.com/81