깃허브 관리도 전략이 필요하다. (스테픈 2km완료)
어제는 저의 깃허브에 README 문서를 처음으로
제대로 꾸몄다고 생각합니다.
그간 readme 부분에 별다른 내용은 적지 않고
단순하게 Deploy 주소정도와
어떠한 프로그램을 사용해서 제작했는지 기술스택 나열정도로만 활용했었습니다.
하지만 어제는 조금 방식을 바꿨습니다.
보통 회사에서 깃허브 주소도 요구하는 경우가 많습니다
처음에는 대수롭지 않게 생각했으나
만약 채용을위해 고민하는 회사에서 나와 스팩과 조건이 비슷한 대상자를 볼때
정말 애매한 상황이라면 깃허브를 들여댜 볼수도 있겠다고 생각이 들었습니다.
그래서 기존에는 이런식으로
성의없게 관리하던 부분을
이제 새롭게 만드는 모든 프로젝트부터 조금더 신경써서 작성하자고 생각하게 되었습니다.
기본적으로 어떤 방식으로 구현을 하고있는지
그리고 어떤 기능이 특징인지 등을
캡쳐해서 올리는 방식인데요
저는 Readme에 사진이 첨부가 된다는걸 모르고 있었다가
가능하다는걸 알게되어 바로 적용했네요
이렇게 이슈 부분에 들어가서
new 이슈를 클릭하고
아무 사진파일이나 업로드 시키면
이런식으로 링크가 생기게 됩니다.
바로 이 링크를 README에 넣어주면 끝입니다.
이런식으로 작성하였고
이렇게 반영됩니다.
전보다 훨신 깔끔하게 작성되었습니다.
그리고 두번째로 중요한 부분인데 바로
생각없이 작성하던 commit 내역입니다.
혼자서 작업하다보면
이런식으로 커밋내역을 아무생각없이 작성하게 됩니다.
혼자 할때라면 모르겠으나
회사에 취업을 하게되면 보통 협업을 통해 코드를 작성합니다.
생각없이 커밋내역을 작성하게되면
서로 어떤 기능이 추가된건지 확인이 어렵습니다.
출처 : https://overcome-the-limits.tistory.com/entry/%ED%98%91%EC%97%85-%ED%98%91%EC%97%85%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B8%B0%EB%B3%B8%EC%A0%81%EC%9D%B8-git-%EC%BB%A4%EB%B0%8B%EC%BB%A8%EB%B2%A4%EC%85%98-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0
저는 이 블로그 글을 참고하여 커밋 내역을 타입에 맞춰 작성하는 방식으로 변경했습니다.
훨씬 직관적으로 변경된 커밋내역을 확인이 가능합니다.
몇가지의 습관이나 작성방법 변경으로
혹시라도 채용을 원하는 회사에서
깃허브를 확인하는 경우
엉망으로 정리가 안되어있는 것보다는 매우 깔끔하게 정리해서 처리하는 모습을 보면
채용의 확률이 조금 더 올라가지 않을까 하는 생각입니다.
스테픈 2km완료
오늘은 힘들군요
