git을 사용하다 보면 이전 커밋으로 되돌아가고 싶은 경우가 있다.

이 때 사용할 수 있는 명령어와 방법에 대해 알아보자.

되돌리기(undoing)

1
2
3

$git restore unread.md

$git restore . // 현재위치 기준 모든 파일의 변경사항 취소

• 커밋 몇 줄을 수정하기에는 너무 많아서 최신 커밋으로 되돌아 가는 방법이다.

unstaging

1

$git reset HEAD unread.md

add한 변경사항을 working directory로 내리는 방법이다.

• 작업한 단위 별로 add하고 커밋을 해줘야하는데, 전체파일을 다 add 해버렸으면 위 명령어로 add한 것을 취소할 수 있다.

직전에 작성한 커밋 수정

1

$git commit --amend

• 바로 직전의 커밋만을 수정하는 방법이다.
• 커밋창이 열리고 메세지를 수정해주면 된다.

직전에 작성한 커밋 삭제

1

$git revert --no-commit HEAD~3..

• –no-commit을 같이 입력해줘야 한번에 삭제가 가능하다. 안그러면 1개씩 커밋을 삭제해나가야한다.
• git commit으로 왜 삭제하였는지에 대해서도 적어줘야한다.

댓글 공유

📌 degit 이란?

degit은 git 저장소의 복사본을 만드는 명령어이다.

git clone vs degit

git clone의 경우 .git 파일까지 같이 가져오므로 파일 용량이 크고 복제하려는 대상이 git으로 관리되고 있다는 내용을 굳이 가져올 필요가 없는데 .git 파일을 가져온 다는 점은 불편하다.

degit은 .git 파일을 다운로드 하지 않아 git clone 보다 훨씬 빠르다는 장점이 있다.

즉, degit으로 복제를 할 경우 버젼관리 없는 새로운 프로젝트를 다운 받을 때 용이하다.

1

npx degit [프로젝트 url] [로컬 디렉토리명]

위와 같이 npx 명령어로 degit을 설치하지 않고 사용할 수 있다.

댓글 공유

📌 리드미란?

리드미란, 다른 사람에게 나의 프로젝트가 얼마나 유용한지를 설명하기 위한 소개글이다.

• 이 프로젝트를 가지고 무엇을 할 수 있는지?
• 프로젝트를 어떻게 사용할 수 있는지?

위 두가지를 목적으로 작성하는 것이 바로 리드미이다.

💡 좋은 리드미 작성법

기본만 잘 따라도 좋은 리드미처럼 보일 수 있다.

1. 프로젝트가 하는 일
2. 프로젝트가 유용한 이유
3. 프로젝트 시작하는 방법
4. 프로젝트에 대한 도움을 받을 수 있는 곳
5. 프로젝트를 유지하고 기여하는 사람

위 5가지가 github에서 언급하는 리드미 작성에 포함되어야 할 정보이다.

💼 오늘 할 일

[x] 리드미 작성 기준에 맞게 리드미 작성하기

위 예시는 내가 과제 제출을 위해 처음에 적었던 리드미이다. 이 리드미를 좋은 리드미 작성법에 맞게 개선해보자.

1. 프로젝트가 하는 일

이 프로젝트는 사용자가 다양한 상태의 업로드 버튼 UI가 필요할 때, 재사용 가능한 컴포넌트를 제공하는 프로젝트이다.

2. 프로젝트가 유용한 이유

• 재사용이 가능한 업로드 버튼 UI를 사용할 수 있습니다.
• 기본 제공되는 버튼 UI가 훌륭합니다.

3. 프로젝트 시작하는 방법

UploadButton

기본적인 사용법은 다음과 같습니다.

1

<UploadButton type="idle">업로드</UploadButton>

타입 설정

아래의 타입을 설정하면 다음과 같은 모양의 버튼 UI가 생성됩니다.

type	shape
idle
pending
resolved
rejected
disabled

4. 프로젝트에 대해 도움 받을 수 있는 곳

만약 프로젝트에 대해 도움이 필요하시다면 아래 이메일로 연락을 주세요!

klj9939@gmail.com

5. 프로젝트를 유지하고 기여하는 사람

https://github.com/loco9939

⭐️ 결과

https://github.com/loco9939/zero-base/tree/icon-upload-button/complete

🏓 소감

리드미란 처음 내 프로젝트를 다른 사람에게 알리는 첫 게시물이므로 사람들이 내 프로젝트를 어떻게 하면 편리하게 사용할 수 있을지, 또 사용하고 싶도록 만들지를 생각하면서 작성해야하는 것을 알게되었다.

이것을 정말 쉽지 않다. 게다가 내 프로젝트에 대해서 정리하여 남에게 설명하는 연습이 잘 되어있지 않아서 낯설고 힘들었지만 아직은 처음이니깐 앞으로 프로젝트를 하게된다면 오늘 배운 점을 고려하면서 작성하도록 노력할 것이다.

댓글 공유

📌 git fork

git fork는 위 사진 처럼 강사님의 원격 저장소의 레포지토리를 나의 원격 저장소로 복제해오는 것이다. 복제해오는 것이지 연결되는 것은 아니다.

사용하는 이유

1. 프로젝트를 할 때, 팀장 원격 저장소를 두고 팀원들이 fork하여 각자의 원격 저장소에서 작업을 하여 분업화가 가능하다.

2. 팀장의 원격 저장소는 배포와 밀접한 관련이 있으므로 직접적으로 팀장 원격 저장소로 코드를 push 하지 못하고 Pull Request를 통해 연결할 수 있으므로 안정적인 개발이 가능하다.

사용 방법 및 주의사항

1. 팀장의 원격 저장소를 나의 원격 저장소로 fork 해온다.

이 때, main 브랜치만 복사해오는 옵션이 있는데, main만 가져오고 싶다면 체크하고 아니면 해제한다.

2. fork한 나의 원격 저장소를 나의 로컬로 clone 해온다.

3. 원격 저장소 목록에 팀장의 원격 저장소를 ‘Leader’라는 이름으로 저장하여 추가한다.

git remote add Leader <팀장의 원격 저장소 URL>

URL이지 git clone 링크와는 다르다.

4. 만약 팀장이 코드를 변경하고 push하여 팀장의 원격 저장소가 바뀌고 이를 나의 로컬로 가져오고 싶다면 ?

git fetch Leader

이 때, 팀장의 모든 브랜치가 아닌 특정 브랜치만 가져오고 싶다면

git fetch Leader <branch 명>

5. 가져온 코드를 내 로컬과 병합해줘야 한다면 ?

git pull Leader <branch 명>

처음 팀장 원격 저장소 fork 해와서 나의 로컬의 main 브랜치는 팀장의 원격 저장소의 main 브랜치와 연결이 되어있다. 정확히는 track 추적을 할 수 있다.

하지만, 팀장의 원격 저장소에서 새로운 브랜치를 생성하였고 나의 로컬에서도 해당 브랜치를 가져오고 싶다면 추가적으로 track 명령어를 실행해줘야한다.

6. 팀장이 브랜치 새로 파고 내 로컬에서 가져오고 싶다면?

git fetch Leader <branch 명>

우선 fetch로 해당 branch를 가져온다.

git checkout -t Leader <branch 명>

내 로컬에서 해당 브랜치로 checkout 하여 브랜치를 옮길 때, -t or track 명령어로 추적한다.

git pull Leader <branch 명>

이제 pull을 받아오면 코드를 가져올 수 있다.

만약 추적을 안하고 가져오게 된다면 변경사항이 없는 상태인데도, pull 해올 때 마다 Merge commit을 하라는 문구가 뜨게될 것 이다…

🏓 소감

수업 중에 강사님 원격 저장소와 연결했는데 문제가 생겼다. 처음 fork 할 때는 강사님 원격 저장소에는 main branch 밖에 없어서 내가 fork 해왔을 때, 연결된 branch는 main branch 뿐이었던 것을 몰랐다.

수업 중 강사님께서 브랜치를 새로 생성하셨고 나도 똑같이 fetch, checkout, pull을 하였는데, 다음과 같은 오류가 발생했다.

“관계 없는 커밋 내역의 병합을 거부합니다”

이러한 오류가 발생한 이유는 새로 생성한 branch를 fetch로 가져오기만 하고 강사님의 원격 저장소의 branch를 추적하지 않기 때문에 발생한 문제였다.

git branch -vv

위 명령어를 사용하면 현재 branch가 어떤 branch를 추적하고 있는지 알 수 있다. 그래서 이미 생성된 branch를 git branch -D <branch 명> 명령어로 삭제한 뒤 위의 방법대로 새롭게 생성한 뒤 추적을 해주었더니 문제가 해결되었다.

앞으로 git 사용하다가 오류가 나오면 무시하지 말고 어떤 오류인지 제대로 파악하고 해결하도록 해야겠다.

댓글 공유

1. Software Development Life Cycle (SDLC)

소프트웨어 개발의 전체적인 라이프 사이클을 이해하여 개발 과정에서 발생하는 일을 정략적으로 관리하자.

해야할 일

1. 요구사항 분석

2. 설계

3. 구현

4. 테스트

5. 유지보수

위 과정을 진행하기 위한 대표적인 모델은 다음과 같다.

1.1. Waterfall

SDLC 일련의 단계를 모든 팀원들이 참여한다. 심각한 문제라면 다시 이전단계로 돌아가야하겠지만, 작은 문제라면 일단 다음 단계로 넘어간다.(작은 문제를 지금 고친다 하더라도 사이드 이펙트 발생까지 생각하기 어렵다.)

장점

• 팀을 관리하기가 편하여 대규모 팀에 적합

• 어떤 단계가 마무리되면 결과가 뚜렷함

1.2. Agile

작은 기능들의 성공을 반복시켜서 프로젝트 완성, 너무 많은 플랜을 지양하고 요구사항에 맞는 코드를 작성한다.

커뮤니케이션 중요(daily scrum, 코드리뷰, 회고)

Daily scrum

매일 15분간 회의를 진행하여 본인이 진행할 기능, 수정사항에 대해 우선순위를 부여하고 순서대로 진행한다.

• Product Backlog: 제품 전체의 요구사항
• Sprint Backlog : 프로덕트 기능 하나하나에 대해서 적어 놓음

Sprint

Sprint는 2주 단위로 진행을 한다. 첫날에 planning meeting을 진행하여 2주간 일정을 세세하게 세운다.

ex) 10월 25일 HTML설계, 10월 26일 컴포넌트 구조 설계 …

회고

2주간의 Sprint가 끝나면 회고를 진행한다.

• 3L 전략(Liked, Learned, Lacked)

Sprint 전 준비사항

1. UseCase 작성하기

UseCase는 flowchart와 다르니 flowchart화 되고 있다면 재고해봐야한다.

UseCase는 사용자가 어떤 행동을 할 수 있는지를 나열하고 이들간의 관계를 연결한 구조로 작성한다.

flowchart가 아니므로 순서를 따를 필요가 없다.

소감

점점 막히는 부분도 많아지고 이전에 제대로 구조를 설계하지 않고 회피하고 구현에만 집중하다보니 리팩터링을 어떻게 시작해야할지 막막하다…

프로젝트 막바지에 다가오니 의욕도 떨어지는 것 같다. 재충전이 필요하다.

그래도 이틀남았으니 내일 하루는 리팩터링에 시간을 쏟고 목요일은 배포와 회고, 발표준비를 하면 프로젝트를 잘 마무리 할 수 있을 것 같다.

댓글 공유

branch

branch란?

분기점을 생성하여 독립적으로 코드를 변경할 수 있도록 도와주는 모델

명령어

1
2
3
4
5
6
7
8
9

$git branch // 로컬 브랜치 확인

$git branch -r // 원격 브랜치 확인

$git branch -a // 둘다 확인

$git branch html-init // 브랜치명 입력하면 브랜치 생성

$git switch 브랜치명 // 브랜치 이동

로컬에서 브랜치 생성한 후 원격 저장소에 push를 해줘야만 github 저장소에 해당 브랜치가 생성된다.

주의사항

• 처음 브랜치를 push 하는 경우에는 -u 플래그를 사용해줘야한다.
  그 이유는 원격 저장소에게 새로만든 브랜치가 main 브랜치와 연관성이 있다라는 것을 의미하기 때문이다.
• 플래그는 맨 앞에 위치하는 것만 아니면 위치는 상관없다.

branch 사용 이유

개발을 할 때, main 브랜치를 두고 개발 브랜치로 소스 코드를 가져와서 원하는 개발을 시도하여도 메인 소스코드에 영향을 주지 않을 수 있어 자유로운 개발을 할 수 있다. 협업에 필수적인 모델이다.

merge

개발 브랜치를 생성한 후 main 브랜치와 합치기 위해서는 merge 작업을 해줘야한다.

1
2

// main
$git merge develop

자신의 역할을 끝낸 즉, merge가 된 브랜치는 바로바로 삭제해준다.

1

$git branch -D develop

merge conflict

만약 main 브랜치와 develop 브랜치에서 같은 파일의 같은 라인을 수정했다면, 컴퓨터는 어떤 것을 선택해야할지 알지 못하므로 그 선택을 우리에게 맡긴다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<!DOCTYPE html>
<html>
  <<<<<<< HEAD
  <head>
    <meta charset="utf-8" />
    <title>git branch practice on branch main</title>
  </head>
  =======
  <body>
    <h1>homepage</h1>
    <p>This work on branch body-init</p>
  </body>
  >>>>>>> body-init
</html>

이럴 경우 원하는 부분을 선택하여 수정해주고 add, commit을 해주면 된다.

1
2

$git add index.html
$git commit

merge를 할 경우, merge commit이 제목과 내용으로 채워져있다.

주의사항

• commit은 항상 동작하는 단위 (최소단위)여야 한다.
• -m 플래그는 사용하지 말자
• merge conflict가 발생한 경우 commit 내용으로 어떻게 충돌을 해결했는지도 적어주자

gitflow 전략

• Master(Main): 사용자를 위한 배포용 소스코드용

• Hotfix: 갑작스러운 버그를 수정하기 위한 브랜치

• Develop: 개발용 브랜치로, feature 브랜치에서 작업한 것들을 이곳에서 모아서 확인한다.

• Feature: 개발자의 작업 브랜치, add와 commit이 작은 단위로 일어나는 곳

gitflow 전략 사용

1. github 저장소에 repository 생성한 다음 나의 로컬 폴더에 git clone 한다.

2. 저장소와 로컬을 연결했다면 저장소를 초기화해준다.

1

$git flow init

3. feature 브랜치를 생성하고 이동하여 작업을 시작한다.

1

$git flow feature start "브랜치명"

기능이나 최소단위로 작업을 진행한다.

4. 작업이 끝났다면 develop 브랜치와 merge한 뒤 feature 브랜치 삭제

1

$git flow feature finish "브랜치명"

위 명령어로 merge,delete 까지 한번에 해줄 수 있다.

5. 기능 개발 마무리되면 release 사용하여 배포 전 브랜치로 이동한다.

1

$git flow release start "버전" // ex) v0.1

위 작업을 통해 버전 태그를 달아준다.

6. release 브랜치에서 github 저장소의 main 브랜치와 develop 브랜치, tags를 push 해준다.

1
2
3
4
5

$git push origin main

$git push -u origin develop // develop브랜치는 처음 github에 올라가니 -u 플래그 사용

$git push --tags // 한번만 해주면 된다.

7. release 브랜치를 merge + delete 해준다.

1

$git flow release finish "버전"

8. github 저장소에서 tag에 가서 release 해주면 된다.

gitflow 전략을 통한 협업

1. 팀장 또는 단체의 repository에서 fork를 하여 복사본은 나의 github 저장소로 가져온다.
   

2. 앞서 사용한 feature 브랜치를 사용하여 개발을 한 후 fork한 사본 저장소에 push를 한다.

3. PR을 하기전 issue 탭에가서 내가 무슨 작업을 할 것 인지 알려주도록 한다.
   

4. 팀장 또는 단체의 repository에 가서 PR(Pull Request)를 한다.

5. 팀장은 나의 PR을 확인하고 요청에 응답하거나 문제가 있다면 코드리뷰를 하며 PR을 보류한다.
   

6. PR이 열려있는 상태에서 나는 나의 develop 브랜치에 돌아가서 코드를 수정한 뒤 commit을 해주면 다시 팀장이 확인하고 끝내 merge를 한다.

• 이 후 팀장이 develop 브랜치와 main 브랜치를 merge하면 issue가 closed 된다.

주의사항

• PR할 때, 나의 develop 브랜치에서 팀장의 develop 브랜치로 PR을 보내야한다.

소감

gitflow 수업이 끝난 후 1시간 30분 동안 4명이서 소규모 팀프로젝트를 경험해보았는데, 아직 머릿속에서 내가 어떤 상태이고 무엇을 해야하는지 헷갈려서 조금 어수선한 감이 있었다.

그래도 피보나치킨 게임(?)을 만들어서 배포까지 해보니 gitflow 전략을 통한 협업의 장점을 느낄 수 있어서 재밌었다.

튜토리얼처럼 단계별로 코드를 따라 치는 것이 아닌 내가 어떤 단계에 있고 어떤 행동을 해야하는지를 생각하며 개발을 해야한다.

댓글 공유