
특정한 프로젝트를 나와 다른 협업자와 같이 작업한다고 가정할 때
우리는 지구 갱생 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를 정리하기가 훨씬 깔끔해졌고 따라서 가독성도 높일 수 있었다.👍
참고