| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 |
- tomcat
- array
- 게시판 리뷰 만들기
- Entity
- 게시판 만들기
- Algorism study
- Spring
- 내일배움카드
- MegabyteSchool
- 패스트캠퍼스
- group study
- Sts
- #패스트캠퍼스 #국비지원교육 #메가바이트스쿨 #MegabyteSchool #개발자취업부트캠프 #내일배움카드
- AWS
- spring boot
- GIT
- View
- Java
- 클래스 상속
- crud
- github
- 개발자취업부트캠프
- #javaStudy
- 국비지원교육
- 클래스 class
- MVC 패턴
- 메가바이트스쿨
- side project
- MVC
- Interface
- Today
- Total
tuter77
2022.12.15 TIL 본문
오늘 배운 것.
<git/github 강의>
● git 관리 전략 (flow)
기본적인 전략은 trunk based flow(기본 브랜치를 trunk 라고 함)로 필요할 때만 분기를 발생시키는 것이다.
때문에 마구잡이로 푸쉬할 가능성을 배제하기 위해서 미리 브랜치를 정하는 전략을 쓴다. 아래는 대표적인 3가지 flow다.
1. git flow
깃플로우는 main과 develop 브랜치를 주축으로 하여 hotfix, release, feature 브랜치로 각 분기를 나누는 형태를 말한다.
main 에서 develop, release 브랜치 후 develop에서 각 기능별로 feature를 브랜치한다. feature 들은 develop에서 merge 되고, develop은 release에 merge해 테스트를 거치고 main에 머지된다.
hotfix는 급히 수정해야하는 사항들이기에 main에서 브랜치후 바로 main으로 머지된다.
main과 develop은 주축인 만큼 하나의 브랜치만 두고 나머지 브랜치들은 기능별, 항목별로 따로 분류한다.
일반적으로 깃플로우는 큰 규모의 프로젝트나 퀄리티 보장이 중요한 프로젝트에서 활용되는 전략이다.
2. github flow
깃허브 팀에서 썼던 전략으로 소규모, 팀규모에서 주로 사용되는 전략이다.
가장 단순하고 효율적인 전략인데, branch를 main, feature들 로만 두어 작업되는 feature들이 main에 바로 적용되게끔하는 전략이다.
실습에서는 이 형태를 사용했다. 왜냐하면 코드가 없어 서비스 배포나 테스트를 할 필요가 없었기 때문이다.
3. gitlab flow
깃 플로우 보다는 효율을 중시하고 깃헙플로우보다는 안정성을 추구한 전략이다.
아래와 같이 4개의 브랜치를 만들어서 메인브랜치가 깃플로우의 디벨롭브랜치 역할을 하게 된다.
production
pre-production
main
feature
main에서 브랜치한 feature가 완료되면 메인으로 머지되고, 작성된 메인은 pre-production 즉 테스트를 위한 브랜치로 나뉜다. 테스트가 완료되어 배포승인이 떨어지면 production으로 브랜치되어 배포된다.
스타트업 규모에 적합한 전략이다. (참고로 실무에서는 이름을 더 명확히 쓴다고 한다.)
● commit convention
커밋 메세지 규칙인데 예로 보면 아래와 같다.
Feat: Add function to login(제목에 해당한다.)
로그인 요청을 위한 함수구현 (본문에 해당)
Close: #1(앞서 배운 이슈번호를 통해 자동으로 이슈를 닫는 역할을 한다.)(꼬리말에 해당)
위의 예시처럼 commit을 작성하려면 이전처럼 커밋 제목만 작성하는
git commit -m " " 의 형태가 아니라 git commit " " 명령으로 터미널 상에서 I > 본문/꼬리말을 작성한 뒤 :wq 로 커밋종료한다.
이렇게 작성된 커밋을 깃허브에 푸쉬할 경우 해당 내용이 모두, pull request에 올라간다.
때문에 무엇을 위해 이 작업을 했는지, 어떤 함수/변수를 추가했는지 등을 자세히 적어주어야한다.
(참고로 이렇게 작성하여도 로그에는 제목만 기재된다.)
*제목 타입 : Feat, Fix, Env, Style, Refactor, .. 등이 있다.
*꿀팁 : 깃헙에서 커밋 로그를 확인 할땐 시계표시를 눌러서 확인할 수 있다.
● issue, pull request template(틀)
이슈나 풀리퀘스트 내용의 기본형태를 미리 만들어두는 파일이다.
git으로 관리되는 폴더 내에 .github 폴더를 만들어서 md파일로 미리 작성한다.(레포에 푸쉬하기전에)(앞의 .은 숨김처리 한다는 뜻이다.)
예시로 하나를 들자면
이러한 형태로 템플릿을 작성한다.
*꿀팁으로 깃헙 파일을 pull하는 과정에서 hint가 뜨는 에러의 경우 commit 이력이 어긋나서 지정하라는 컴플릭트이다.
이런 경우엔 git pull origin main --no-ff 로 해결하면된다.
● 이슈마다 템플릿 만들기 기능
깃허브에서 기존에 작성되어있는 템플릿을 이슈 타입에 따라 만들 수 있다.
settings > issues > set up template > add template 순으로 만들면 된다.
이슈 생성시에 각 템플릿을 선택하면 된다.
● branch pretection
main에 바로 push를 하거나 코드리뷰없이 merge하는 경우를 방지하기 위해 설정한다.
즉, 해당 권한을 차단하는 기능이다.
깃허브에서 settings > branches > add branch > rule 로들어가 설정할 수 있다.
예를 들면 첫번째 항목은 특정 브랜치로 푸쉬하는 것을 제한하는 옵션이다.
이때에 비슷한 이름의 브랜치가 많다면 feature*로 모두 feature가 들어간 모든 브랜치에 푸쉬가 불가능하도록 설정하는 방법이 있다.
● git ignore
DB접큰 키나 AWS 인스턴스 키파일 등이 git push에서 깃허브에 공유되지 않도록 설정하는 기능이다.
에디터에서 .gitignore 파일을 생성하여 해당 파일안에 깃 관리를 받지않을 중요파일명을 기재하면된다.
단, 이 과정 전에 이미 키파일을 add, commit 했다면 이 기능을 해도 의미가 없다.
때문에 그런 경우에는 git rm -r --cashed 명령을 사용하여 캐시를 지울 필요가 있다.
이것으로 할당된 git강의가 종료되었다. 과정이 즐거워서 아쉬웠지만, 실습에서 적용해볼 수 있는 장면들이 많아 많이 배웠다.
후에 다른 협업 실습, 사이드 프로젝트 등에서 유용히 이용해야겠다.
<java>
● 자료형
문자 > 정수로 표현 하는 것을 문자 인코딩이라고 한다.
예를 들어 A > 65 로 변환하는 것을 인코딩, 반대로 65가 A가 되는 것을 디코딩 이라고 한다.
이러한 인코딩/디코딩은 문자 세트를 통해 작동한다.
문자세트는 ASKII 코드, euc-kr, utf-8, utf-16 등이 있는데, 자바는 utf-16 인코딩을 사용하며 기준은 세계표준 UNICODE이다. (앞선 예시의 A가 65라는 내용도 unicode에 정리되어있다. B는 66인 식)
utf-8은 1에서 4바이트를 유동적으로 사용하기에 네트워크 서버에서 주로 사용된다.
*팁으로 char 'a' 와 "a"는 바이트의 차이가 있기때문에 다른것으로 인식한다.('a'는 문자형이고 "a"는 문자열형이다-str)
또 다른 예시로 인코딩은 char ch = 'A'; 와 같이 선언했을 때 숫자로 표현해도 문자가 출력될 수 있다.(단, 양수만 가능하다.)
char ch1 = 65 는 동일한 문자가 출력된다.
나아가 유니코드로 출력하려 한다면 \u코드 값으로 표현할 수 있다. (유니코드표 참조, 16진수)
●논리형
true. false 두가지만 나타내는 1바이트짜리 자료형이며, 값이 존지하는지, 배열이 비었는지, 결과의 참거짓을 표현한다.
*(string[] args) 는 파라미터라고 불리는 매개변수이다.
*java는 python,JS 같은 스크립트형 언어가 아닌 컴파일형 언어이기때문에 한번선언한 데이터 타입에 맞는 자료형만 입력해야한다.
●상수(constant)
변하지 않는 수로 원주율, 1년 12개월 등이 있다.
사용시에는 final이라는 예약어로 선언해서 사용한다. 또한 상수는 MAX_NUM과 같이 이름을 대문자로 작성한다.
●리터럴(literal)
프로그램에서 사용하는 숫자, 문자, 논리값을 뜻하며, 리터럴은 상수풀(constant pool)에 저장된다.
● 형 변환(type conversion)
다른 타입의 자료들을 연산할 경우 연산이 되지 않기 때문에 형 변환이 있어야된다.
예를 들면 정수 + 실수 는 정수 > 실수 실수 + 실수와 같은 형태로 형변환 후 연산이 이루어진다.이러한 형변환엔 묵시적형변환과 명시적형변환이 있는데, 묵시적 형변환은 바이트 크기가 작은 타입에서 큰 타입으로 자동으로 변환되는 경우다. (예로 정수(int) > 실수(long))반대로 바이트 크기가 큰 타입에서 작은 타입으로 변환하려면 명시적 형 변환이 필요한데 이 과정에서 자료의 유실이 일어나므로 프로그래머가 직접해야한다. (예로 3.14 > 3 과같이 변하는 경우)
오늘은 커리어 특강이 있어 온라인 자바강의를 많이 학습하지 못했지만, 기본개념의 틀을 잡아간다는 생각으로 천천히 하고 있다. 강사님이 알려주시고 싶으신게 많아 사이사이 앞선 정보들이 난무했지만, 그래도 차분히 따라가 봐야지.
'TIL' 카테고리의 다른 글
| 2022.12.18 TIL (0) | 2022.12.18 |
|---|---|
| 2022.12.16 TIL (0) | 2022.12.16 |
| 2022.12.14 TIL (0) | 2022.12.14 |
| 2022.12.13 TIL (2) | 2022.12.13 |
| 2022.12.12 TIL (0) | 2022.12.12 |