2022.12.14 TIL

오늘 배운 것.

 

13:00 ~ 15:00 까지는 어제 배운 git/gitgub을 간단히 복습한 뒤 온라인 강의 Java 편을 수강했다. 

 

<JavaScript>

●먼저 eclipse라는 에디터 프로그램을 사용해 javascript를 실습했고, 사용한 단축키는 아래와 같다.

 

새 프로젝트 만든 후, 

패키지 만들기 ctrl + n > 패키지 선택 

패키지 내 클래스 만들기 ctrl + n > class 선택 

 

패키지 명은 소문자영문으로 만들고 클래스명은 대문자 영문으로 시작한다. 

코드라인 지우기 ctrl + D

저장 및 실행 ctrl +F11

 

class 내에서 코드를 작성하는데 코드 중 main은 서버가 아닌 로컬에서 코드를 구동하기 위해 사용한다고 한다.(그렇다면 main 자리는 어디서 구동하는지에 대한 정보를 기재할 것.)

 

이클립스 내 설정에서 build Auto에 꼭 체크 해야 저장 및 자동 컴파일이 실행된다.

컴파일 되기전 작성된 클래스는 src(소스) 폴더에 저장되고, 컴파일 된 클래스는 bin(Binary)폴더에 저장된다.

실제 구동은 컴파일 된 bin폴더의 클래스에서 이뤄진다.

 

또한 출력하기위한 명령어 구문은 이렇다. System.out.println(""); 이 중 시스템 첫 알파벳이 왜 대문자인지와 아웃은 어떤 의미인지 모르겠지만, 프린트라는 구문은 출력하라는 명령어임을 알겠고, ln은 줄바꿈을 명령하는 것을 알겠다.

 

● 컴퓨터에서 자료형 표현하기 

컴퓨터는 익히 알다시피 2진수로 표현한다. 0과 1로 이루어진 2진수는 1bit로 표현된다.

또한 실생활에서 사용하는 10진수는 길기때문에 2진수, 8진수, 16진수로 표현한다.

이 파트에서는 일전에 정보처리기능사를 공부한 내용덕에 쉽게 이해됐다.

특히 각 진수의 숫자를 2진수로 변환하는 부분에선 8421 코드를 적용하면 되었다.

 

예시) 10진수 10 > 2진수 1010 (2^3 +2^1) (첨 : 1010을 8421의 숫자로 보면 8자리에 *1 더하기 2자리에 *1하여 옆과 같은 10이 된다. 추가적으로 8진수는 421로 16진수는 마찬가지로 8421로 변환하면 된다.)

 

int는 정수를 선언하는 자료형이다.

8비트에서 맨 앞자리는 부호이며 양수는 0, 음수는 1로 표기한다.

예시)5를 8비트로 표현하면 0000 0101 > 4+1=5

1 개의 비트 0 1  2^1개 표현

2 개의 비트 0, 0  0, 1  1,0  1, 1 0~7까지 2^2개 표현 

4 개의 비트 2^3개 표현 

 

자바 내에서 2진수는 0B를 앞에 붙이고, 8진수는 O를, 16진수는 OX를 붙여준다. 

예) 10진수 10은 16진수로 OXA

 

int bNum = 0B1010

int oNum = O12

int oxNum = OXA

각 변수를 System.out.println(변수명)으로 각각 출력해주면 모두 10으로 출력된다.

 

변수는 값을 담는 자료구조로써 Variavle var로 표기한다.

자료형이 문자, 줄, 정수, 실수 등으로 다양하기 때문에 자료형(데이터 타입)에 따라 변수의 용량이 달라진다.

때문에 자료형을 먼저 선언해 변수에 어떤 자료형을 담을지 결정해야한다.

 

변수 이름은 영문자, 숫자, 특수문자($, _)로 구성할 수 있으며 시작은 영문자로 작성한다. 

또한 예약어는 사용할 수 없다.(while, break)

이와같이 변수는 용도에 맞고 가독성이 좋게 이름짓는 것이 중요한데 최근엔 numOfStudent 와 같이 소문자로 시작해 단어가 바뀔때마다 대문자를 사용하는 트렌드이다.

 

정수표현은 byte, short, int, long 으로 구분되며, 실생활에서 사용하는 10진수 대부분은 int로 값을 저장한다. 각각 1바이트, 2바이트, 4바이트, 8바이트로 구성되어있다.

문자형은 char로 저장하며, 2바이트이다.  

실수형은 float, double로 구성되며 따로 지정하지 않으면 double로 저장된다. 각 4바이트, 8바이트로 구성되어있다.

논리형은 boolean이라는 1바이트에 저장된다.(참, 거짓 0,1로 표현가능)

 

정수형에서 바이트는 1바이트 단위의 자료형 동영상, 음악, 실행파일 등에 사용되고, short는 사용이 적으나 2바이트 단위의 C/C++ 언어와 호환시 사용한다.

int는 기본 정수 자료형으로 4바이트 단위이며, 프로그램내에 기록되어진 10진수 값들(리터럴)을 표현하며, 32비트가 초과하는 숫자는 long자료형으로 처리한다.

long 자료형은 숫자 뒤에 l을 기재하여 long형임을 표기하여야 인식할 수 있다. (ex. 12345678900l)

(이와 유사하게 실수형 float는 마지막에 f를 붙여줘야 인식할 수 있다.)

 

실수표현에서 부동소수점 방식은 한정된 비트안에서 정수부와 소수부를 나누어 표현하게 되는것에 한계가 있어 사용하게 되었다. 

예) 0.4 * 2^-1 이와 같이 표현되는 실수는 가수 * 밑수 ^ 지수로 구성되어있는데 , 정규화를 하면 가수의 정수부분은 1이되고 밑수는 2로 고정하여 1.6 * 2^-3의 형태가 된다.

[1.m * 2^-n]

 

변수, 자료형, 2진수, 10진수 등의 개념들은 정보처리기능사 공부를 했던 기억이 나 쉽게 이해할 수 있었지만, 정규화 개념은 아직 정확히 파악하진 못했다. 다음 강의에서 자세히 알아봐야겠다.

 

<git 12.14>

 

● branch : git의 자체적 기능으로 분기라는 의미다. commit을 하다보면 version을 분기화 하는 것이다. (예: 배포/테스트/개발용 버전 구분을 위해)

 

branch    | commit log                                |  파일 상태

main       | commit1 > commit2 > commit3 | commit 1,2,3

develop  |                                 > commit4  | commit 1,2,4

 

위와 같이 브랜치 설정 후 서로 영향이 없는 걸 알 수 있다.(파일과 커밋 기록이 별도로 관리된다.)

 실무에서는 버그 픽스, 배포용, 기능 별로 브랜치를 생성해서 각각 개발을 진행하고 개발완료 후 브랜치를 한로 통합(merge)해서 서비스를 완성하는 방식으로 진행한다.

 

아래는 branch 관련 git 명령어 모음이다. 

main 을 고정 브랜치 이름으로 설정:  git config --global init.defaultBranch main

branch 이름 변경 : git branch -m main (-m은 이름 변경 옵션이다.)

branch 생성 : git branch (브랜치 명) 또는 git switch -c (브랜치 명) 

branch 확인 : git branch --list

기 생성된 브랜치로 변경 : git switch (브랜치 명)(switch는 chekout 명령어와 유사하지만 최근에는 switch만쓴다고 한다.)

branch 삭제 : git branch - d (브랜치 명)

 

위 처럼 기능 작업을 분업하기 위해 branch를 활용하여 각각 작업을 한 뒤, 뒤에나오는 merge를 통해 하나의 파일로 통합한다. 

(브랜치 명은 일반적으로 기능별로 작성한다. feature/#5와 같이 github내에서 issue로 주어진 작업내용을 브랜치 명으로 생성한다.)

 

● merge 

merge는 branch로 나뉘어진 기능 (feature)들을 합치는 것이다.

merge를 실행할 경우 git의 관리하에 있는 로컬저장소의 기록들이 하나로 합쳐진다. 또한 파일의 내용역시 합쳐진다.

때문에 merge는 신중히 실행해야할 것임을 명심해야한다.

 

아래는 merge와 연관된 명령어이다.  

rm -rf .git : .git 폴더를 지워 해당 로컬저장소의 git에 관한 정보를 초기화한다. (기록을 초기화시켜 merge 실습을 하기위해 사용했다.)

git merge (브랜치 명) : 현재 브랜치(head)에 따로 작업한 브랜치 작업파일을 합친다.

git log : 상세한 git 기록 내역을 불러온다.

git log --oneline : 한줄로 git 기록내역을 불러온다. 

git log --oneline --graph --decorate : git 기록 내역들이 분기에 따라 나뉘었다가 머지로 합쳐진 것을 그래프로 보여준다.

 

!. merge를 하다보면, 코드라인이 겹치는 경우 comflict(충돌)가 발생한다. 이런상황에서 VSC는 어떤 방향으로 합칠지 선택 옵션을 제공하게되고, 선택을 하고 나면 정상 merge가 이루어지게 된다. 

주의할 점은 이후 Etc: Merge develop to main 과 같은 형태로 재 커밋해야 한다는 점.(로컬 저장소 내에서 이뤄지는 머지 컴플릭트는 머지를 목적으로 행한것이기에 컴플릭트와 관련된 내용은 커밋메세지에 기재하지 않는다.)

 

*꿀팁으로 이러한 상황을 방지하기 위해 각자 다른 파일을 맡아서 작업하거나, 같은 파일을 작업할 경우 함수를 다르게 작성하여 헷갈리는 일이 없도록 해야한다고 한다.

 

● fast-forward 

한 줄로 나열시키는 머지방법인데, 추천되지 않는다고 한다. 

이유는 한줄로 나열시키면, 어떤 브랜치에서 누가 작업했는지 등의 로그가 사라지기 때문에 확인하기가 힘들다는 것이다.

 

branch    | commit log                                |  파일 상태

main       | commit1 > commit2                   | commit 1,2

develop  |                                 > commit3  | commit 1,2,3

 

이와 같은 형태일때 merge를 실행하면 패스트 포워드가 일어나 한줄로 로그를 정리시켜 버린다. 

때문에 git merge develop --no-ff 옵션을 사용해 패스트 포워드가 일어나지 않도록 방지해야한다.

 

● rebase 

특정 브랜치를 기준으로 놓고 커밋 이력을 일렬로 정렬 시키는 명령어다. 

일반적으로 복잡한 로그의 경우 적용하여 정렬시키는 목적으로 사용되며, 머지하는 경우가 아니어도 사용한다고 한다.

실제 사용은 특정 프로젝트에 FORK할때 주로 사용한다고 하는 데 현재의 내 수준에선 사용할 일이 적을것이라고 배웠다.

리베이스에도 머지와 같은상황에 컴플릭트가 발생하는데 

git add . > git rebase --continue 를 사용하여 컴플릭트를 해결할 수 있다고 한다.

 

● pull request

앞서 설명한 개념들은 로컬 저장소 내 git에서 사용하는 것 위주였다면 풀리퀘스트 부터는 github로 이동한다. 

이미 브랜치도 생성했고,  깃허브와 연결도 된상태고, 각 브랜치의 작업을 끝내서 깃허브로 푸쉬하게 되면 이 풀 리퀘스트의 형태로 main(실무에선 시니어 개발자) 브랜치에 도달하게 된다. 

즉, 작업이 완료되었으니, 병합을 요청하는 것.

이 때 리퀘스트를 작성하는 원칙은 아래와 같다.

 

## 담당 기능 

-이름 (이 옆에 Close issue 넘버를 적으면 issue와 연동되어 머지수락 시 이슈도 해결된다.)

##변경 사항

-[ ]세부내용

 

풀 리퀘스트를 요청받게 되면, 해당 코드를 리뷰할 수 있고 검토/수정을 거쳐 머지에 이르게 된다.

코드리뷰는 file changed 항목에서 각 코드마다 리뷰할 수 있으며, 리뷰를 끝낼땐 finish (comment, approve 등) 세가지 선택지에서 선택해야한다.(자신의 풀리퀘스트는 코멘트밖에 달 수 없다)

이후 머지된 main의 레포를  각 브랜치 담당자들이 git pull 명령어를 사용하여 내려받을 수 있다.

주의할 점은 리퀘스트에 사용된 브랜치는 머지이후 즉시 삭제해주는것이 혼란을 방지할 수 있는 예방책이라는 것이다.

실습때 나도 까먹었지만, 꼭 잊지말자.

사용된 브랜치는 git fetch --prune으로 로컬저장소에 정보를 내려받고, 앞서 배운 git branch -d (브랜치 명)옵션으로 로컬내에서도 브랜치를 삭제할 수 있다.

 

풀리퀘스트 역시 머지와 같이 컴플릭트 상황이 발생하는데, 그럴 경우 에디터로 다시 pull하여 작업한 브랜치에서 main의 코드를 머지하여 해결한다.  그 이후 다시 push 하면 컴플릭트가 해결된다.

(이 때에 commit메시지에 for resoved comflict와 같이 부연을 달아주는데, 머지만 하려고 한것이 아니라 컴플릭트를 해결하기 위해 머지를 행한것이기 때문이다.)

 

머지와 풀리퀘스트 개념들은 협업을 위해 꼭 필요한 개념이지만, 서로 공유하는 방식이 늘 궁금했어서 그런지 굉장히 재밌게 수강할 수 있었다.

 

< github 자체 기능활용>  

● issue / label / milestone

 

이슈는 할일 정리의 용도로 사용된다. (구현할 기능/ 버그 필스 등) 오픈소스일 때와 일반적인 사용에서 차이가 있지만, 일반적으로 사용할 때 굉장히 유용한 기능이다.(할일 체크리스트) 

앞서 말했듯 각 브랜치 명을 이 이슈에서 할당된 번호로 작성하는 만큼, 프로젝트를 시작할 때 먼저 협의하고 작성해야하는 항목이다. 

이슈내에는 라벨과 마일스톤을 선택할 수 있는데, 라벨은 이슈가 어떤 카테고리(ex. bug, feat 등)에 속해있는지 알려주는 역할을 하고, 마일스톤은 이슈들의 집합으로서 현재 프로젝트 진행도가 얼마나 진행되었는지 확인할 수 있는 카테고리이다.(일반적으로 버전별로 마일스톤을 나누고 이슈에 필요한 라벨을 만든 후 이슈를 만든다)

 

● wiki 

프로젝트 관련하여 버전에 관한 정보, 라이센스에 관한 정보, 프로젝트에 기여하는 방법 등을 기재하는 기능이다. 

실습과정에서는 팀 끼리의 커밋 메시지 타입을 올려둔다(이름규칙)

 

●github actions

연차가 쌓일 수록 필요해지는 기능으로써 자동 배포설정, 테스트 브랜치에 푸쉬되면 자동 테스트 등의 기능을 갖고있다.

 

●github pages 

github.io 주소로 자신의 웹사이트를 배포할 수 있는 기능이다. 

레포를 만들 때 유저명.github.io 로 생성하면되고 사이트 내부 디자인 등은 VSC에 해당 폴더를 만들어 작업하면된다.

이때 index파일로 html, css등이 작업 가능하다.

선생님의 추천은 hexo로 깃헙 블로그를 만드는 것이었다.

 

git 강의는 전체적으로 프로그래밍이 협업을 전제하고 각 기능별로 따로 작업한다는 것을 확실하게 알려주었다.

팀 실습을 진행할 때 서로가 각자의 파트로 나뉘어져 작업한 후 최종본으로 내려받을 때 짜릿한 즐거움이 있다는 걸 알게되었다. 본인 업무를 개인적으로 작업하는 것도 좋지만 레고처럼 딱딱 맞아떨어지는 협업에서 오는 즐거움이 있는것 같다.

 

오늘 많은 내용을 다뤘지만, 그래도 뺄것하나 없이 다 실무에서 필요한 것들로 구성되어있어 굉장히 만족스러웠다.

내일도 실습이 있다니 기대되는 부분이다.