특정한 프로젝트를 나와 다른 협업자와 같이 작업한다고 가정할 때
우리는 지구 갱생 project
의 step1
브랜치에서 같이 작업을 하는 중이다.
그런데 코로나 때문에 자가격리를 하면서 따로 프로젝트를 진행해야 할 상황에 처해졌다.
따라서 우리는 step1-inwoodev
그리고 step1-John
이렇게 브랜치를 나눠서 같이 작업을 한 뒤
차례차례 merge
를 해서 작업물을 합치기로 했다.
나부터 작업을 시작했다.
git pull origin step1
을 통해 remote repository
의 작업물을 local repository
로 불러온뒤 열심히 코딩을 했다.
오랜만에 John과 티타임을 가지며 같이 작업물을 확인한 뒤 이제 병합을 하려 한다. 내 작업물이 조금 더 나은 것 같아서 내 작업물을 step1
에 최종 merge하기로 결론지었다. 따라서 나는
iterm
을 열고...
~/지구 갱생 project > step1-inwoodev >
위치에서
git add
git commit -m "commit message command"
git push origin step1-inwoodev
step1-inwoodev
작업물을 다 remote repository
에 올려보낸다.그 뒤 step1
로 checkout
한 뒤 step1-inwoodev
의 작업물을 step1
으로 merge
를 실행한다.
~/지구 갱생 project > step1-inwoodev >
git checkout step1
~/지구 갱생 project > step1 >
git merge step1-inwoodev
git config --list
git config --global user.email
*적혀져 있는 이메일주소와 github
의 이메일 주소가 들어 맞는지 확인하자
git checkout
_ _ _
-- file
working directory에서 수정한 특정 파일(git add이전)을 현재 버전으로 되돌리기
git reset
_ _ _
commit number
commit number
전체를 입력할 필요는 없다. 6숫자 정도면 OK--hard commit번호
git reset --hard 6558d8
--soft commit number
-merge ORIG_HEAD
git revert
_ _ _
commit number
--mainline 숫자
가위바위보
와 묵찌빠
를 구현 하기 위해서 @Neph와 제가 가장 고민 했던 부분은 각 메소드에 기능을 최소화
하면서 코드의 간결성
과 가독성
을 높이는 것이었다.
코드를 작성 중 input 값
으로 받은 optional String 값
을 Int 값
으로 가져와야 하는 상황이 있었다. 이 상황에서 우리는 guard let 문
을 두 번 사용하였는데 우리가 생각하기에 이는 조금 비효율적인 것 같다는 인상을 받았다. 하지만 딱히 다른 방법이 오늘은 생각이 나지 않았기에 그대로 진행하였다. 추후에 피드백을 받은 뒤 더 나은 방법이 생각나면 수정하면 좋겠다.
세부 메소드를 구현 하기 전 같이 메소드의 청사진
을 그려보며 프로그램의 뼈대를 세우는데 먼저 많은 시간을 할애하였다. 전반적인 청사진이 그려지니 코드를 구현하는데에는 그리 오랜시간이 걸리지 않았다.
가위바위보
에서 더 나아가 묵찌빠
를 만들기 위해 부모 클래스
와 상속 클래스
를 활용해서 둘의 관계와 기능을 정의 해 보았습니다. 부모 상속 관계
를 형성함으로써 묵찌빠의 메소드 중 묵찌빠에도 해당 되는 메소드를 바로 불러올 수 있어서 좋았고 비슷한 기능인 경우 override
를 함으로써 더욱 효율적으로 코드를 작성할 수 있었다고 생각한다.
Enum
, Error Handling
, 그리고 switch
와 함께라면 뭐든지 할 수 있다 🤩
Enum
과 Error handling
을 통해 사용자 입력값을 받을 때 일어날 수 있는 오류처리를 하니 프로그램이 조금 더 안정적으로 돌아갈 수 있게 된 것 같다. 👍
마찬가지로 Enum
과 switch
를 활용하니 예외 case를 정리하기가 훨씬 깔끔해졌고 따라서 가독성도 높일 수 있었다.👍
참고