개발공부 기록지

처음 repository 를 파고 나서 설정을 다하면

main 에서 시작을 하게 된다.

이때 바로 main에 commit 을 하지 않고

새로운 branch를 만들어준다. ex) main 에서 develope 생성

develop로 옮겨서 이제 각자 맡은 기능에 맞게 

또 branch를 만들어준다. ex) develope 에서 feature/user 생성

main - develpe - feature/user

                           - feature/posts

와 같이 생성이 되고 각자 맡은 기능을 구현하고 나면 develope에 Pull request(PR)을 해주면 된다.

여기서 항상 주의할 점은 새로운 branch 를 develope에서 생성할 때

꼭  git pull 을 쳐서 최신상태로 업데이트 해야한다.

안그러면 충돌이 발생.

만약에 다른 팀원이 먼저 PR을 한 후 나의 코드를 PR을 할 때도

merge충돌이 생길 것이다.

이때는 다른 팀원이 작성한 것은 보존하고 내가 작성한 코드만 살리면 된다.

(궁금) 다른 팀원이 나 feature/user 부분 다했어 하면 내가 하고 있는 feature/posts 에서 업데이트해버리는 방법은 없을까?

stage : add 해서 버전 추적 중인 파일들이 있는 공간

git reset

- 3 가지 옵션이 있다. ( --soft, --mixed(기본 옵션) , --hard) 

- (기본옵션) 인덱스는 삭제되지만 작업영역 디렉토리는 영향을 받지않는다.

• 즉, 커밋한 로그는 사라지지만 파일은 보존
• Head 도 커밋하기 이전으로 이동 
• 선택적으로 커밋을 한 것을 골라서 제거 가능

git reset --hard

- 커밋한 로그, 파일까지 지우고 커밋하기 이전으로 이동한다.

- push 하지 않은 사항을 모두 제거

그러면 이 둘은 언제 사용하는 것이 적합할까?

git reset

• 커밋취소하고 변경사항 반영
• 병합 취소

git reset --hard

• 잘못된 코드 작성
• 실험적으로 변경 후 되 돌리기

git reset --hard 는 디렉토리까지 지우므로 적용하기전에 백업해두는 것도 고려해봐야 할듯

충돌이란?

깃이 자동으로 병합을 완료 할 수 없는 상황을 말한다.

(예) 두명의 개발자가 각자의 브런치에서 동인한 코드를 수정했을 때 깃 입장에서는 어떤 변경사항을 최종적으로 반영해야 하는지 알수 가 없다.

충돌 발생시키기

1. main 에서 코드를 수정하고  커밋 및 푸쉬 를 한 후

2. 브랜치에서 하나의 기능을 추가 한후 커밋을 한다.

3. 다시 main 으로 돌아와서  병합을 시도

자동 병합: test.py
충돌 (내용): test.py에 병합 충돌
자동 병합이 실패했습니다. 충돌을 바로잡고 결과물을 커밋하십시오.

위와 같은 메시지가 출력 될 것이다.

충돌 해결하기

충돌이 일어난 코드를 확인

<<<<<<< HEAD (현재 변경사항)
print('hello' * 3)

# check odd number
num = int(input("Enter a number: "))
if (num % 2) == 0:
    print(f"{num} is Even")
else:
    print(f"{num} is Odd")
=======
print('hello ' *3)

# check odd number
num = int(input("Enter a number: "))
if (num % 2) == 0:
    print("{0} is Even".format(num))
else:
    print("{0} is Odd".format(num))
>>>>>>> dev2 (수신 변경사항)

• <<<   >>> 이 충돌이 일어난 구간을 알려주는 기호
•  ==== 는 구분해주는 기호 

여기서 무엇을 제거하고 저장할 것인지 결정하고 남겨둔 후 

메인에서 최종본만 남겨두고 충돌을 알려주는 구문을 제거하면 된다.

git add .
git commit -m "resolve conflicts"
git push -u origin main

확인

git log --pretty=oneline --graph

아래와 같이 커밋 내역을 확인 가능

*   d3...be6 (HEAD -> main, origin/main) resolve conflicts
|\  
| * 484...778 (dev2) add pow
* | e5b..17 fit: check odd number
|/  
* ef1...9bbc squash & merge
* 4df..a20126 first commit

브랜치(branch)

프로젝트 기준 코드인 main 으로 부터 독립적인 작업공간을 만들어주는 기능

명령어들

#브랜치 생성
git brance -b branch_name

# 브랜치 삭제
git branch -d branch_name #지역 저장소의 브랜치 삭제, 병합여부 확인
git branch -D branch_name # 지역 저장소의 브랜치 삭제, 확인 없이 삭제


git push origin -d branch_name #원격저장소의 브랜치 삭제 

# 브랜치 이동
git checkout branch_name

현재 실습 프로젝트의 브랜치 상태 확인

git log --pretty=oneline --graph

브랜치 병합하기

Squash merge : 모든 커밋이력이 아래 그림과 같이 하나로 된다.

git checkout main
git merge --squash branch-name
git commit -m "squah and merge"
git push -u origin main

https://swagger.io/docs/specification/paths-and-operations/

Swagger 의 데이터 형식은 YAML 을 이용한다.

• YAML작성법 참고: https://joey0203.tistory.com/114
• Swagger 공식문서 참고 : https://swagger.io/docs/specification/paths-and-operations/

Node.js 에서 사용 할때 설치 해야 할 라이브러리

npm i swagger-jsdoc swagger-ui-express

• https://www.npmjs.com/package/swagger-ui-express
• https://www.npmjs.com/package/swagger-jsdoc

작성시 주의 할점

- 공백을 잘 처리해서 구조화 해야한다. 탭 사용 X 스페이스바로 구별

- 내가 못 찾은 것일 수도 있지만 계층적 구조로 내려갈때 몇칸을 띄워서 구분하는지 설명이 없다..

    - 에러를 통해서 경험해본 결과 보통 1~2칸 으로 처리 하는 듯 하다.

예시

/**
 * @swagger
 * /maps/{station}:
 *   post:
 *     summary: station 위치 조회 및 맵에 표시
 *     description: 선택된 역에 있는 위치만 맵에 표시
 *     parameters:
 *      - in: path
 *        name: station
 *        required: true
 *        description :  the name and location of the station
 *        schema:
 *          type: string
 *
 *     responses:
 *       200:
 *         description: 조회 성공
 */
 
router.post('/:station', async (res, req) =>{
	res.status(200).send('test);
})

정말 어렵다고 여겨지는 것이 큰 틀이 없다.

위의 파라메터를 작성할 때 공식 문서에는 in: 부분이 먼저인데 name을 먼저 사용해도 아무 문제 없다.

띄어 쓰는것 도 상황에 따라 다른것 같다...

아직 모르겠다..... 공식 문서에서는 2칸씩 띄우니까 이대로 따라해야지

끝없이 에러가 발생한다면...
한 줄씩 작성하고 테스트하면서 에러를 줄여가자!!