Hello World!

아마추어라 더 심오한 기능을 이해하지 못하고 겉면만 핧는 이야기가 될수도 있다고 생각하지만 Git의 가장 좋은 기능은 Commit이라고 생각한다.

특정 부분에서 특정 부분까지 무슨 작업을 했는지 메모를 달아서 기록을 남길 수 있는 부분이 가장 강점인듯 싶다. 비슷한 도구가 있는지는 모르겠지만...

그것 외에도 branch를 분기시켜서 추가기능이나 코드 수정등을 한 다음 본래 master에 merge시키거나

분기를 갈라서 합치지않고 비슷하지만 다른 여러종류의 프로젝트를 하나의 프로젝트 파일 내에서 관리할수있거나 하는 등의 활용법도 좋다고 생각한다. 일반적으로 잘 쓸거같지는 않지만...

Github같은곳에서 보면 협업기능도 많이 강조되는것 같다. 로컬라이징같은 작업을 할때 분업하기도 편하고 잘 모르는 부분에 대해서 잘 아는 사람이 직접 수정을 해서 작업물을 pull해주면 그걸 merge해서 프로젝트를 탄탄하게 만드는 과정도 좋은 부분이라고 생각한다.

다만 단점이라면 기본적으로 cui환경에서 다루어지도록 짜져있어서 그런지 gui환경의 툴로는 완벽하게 제어가 되지않아 cui환경에서의 작업방법도 알아둬야한다는 점이다. 그리고 맨 처음 commit이나 forking merge 등의 기능에 대해 이해하기도 힘들고말이다.

그리고 한번 commit하면 그걸 되돌리는 작업이 꽤나 번거롭고 힘들기때문에 Commit을 할 시점을 잘 골라야 한다는 점도 있다. 물론 VS에선 예전 코드와 현재코드를 같이 볼 수 있으니까 수동으로 되돌리기도 비교적 쉽고 기능 자체로 아예 revert가 가능하니 잘 다루는 사람이라면 크게 문제가 될것은 없다고 생각한다. 

필자는 알려주는 사람도 없고 기초적 지식도 없어서 혼자 Git 가이드를 몇번씩 읽어보고 직접 테스트해가면서 매우 기초적인 작업은 수행할 수 있도록 되었지만 아직도 revert등의 작업이 낮설다. 뭐 하여튼 cui툴도 다룰 줄 알아야 한다는 점이 의외의 장벽이 될 수도 있다고 생각한다.

나중에 쓸지도 모르지만 Fork는 사본 복사, Repository는 프로젝트 및 솔루션, fetch는 update라 생각하면 편하다고 본다.

세세한 정의와 메커니즘은 다르지만...

https://help.github.com/articles/configuring-a-remote-for-a-fork/

https://help.github.com/articles/syncing-a-fork/

일단 원본의 변경내역을 사본에 병합하기 위해서는

git merge [원본사용자명] [브랜치명]

이렇게 명령어를 써주면 가능하지만 fetch를 해주지않으면 최신 변경내역이 적용되지않고 forking한 시점의 head가 그대로 남아있기때문에 fetch를 해주는것이 필수

웹페이지나 어플리케이션에 탑제된 기능으로도 merge가 가능하긴하지만 난 콘솔로 한 다음 vs로 충돌내역을 정리하는 식으로 작업한다.

충돌을 줄이는 법이 있을것 같긴하지만...

기초부터 튼튼하게, 콘솔로 배워야 한다고 하는 사람들도 있다고 생각하지만 일단 기초적인 기능을 사용할 수 있는 수준이 되고 실제로 실습을 해봐야 이해가 가는 부분도 있다고 생각.

콘솔로 다루는것이 확실히 정확하고 git의 대부분의 기능을 활용할 수 있는것은 맞지만 일단 시각적으로 보거나 누구에게 배우지 않고서는 이해하기 힘든 사람들도 있다고 생각하고...인터넷에 범람하는 쉬운 Git따라잡기 가이드들이 그 표본들이라고 생각함.

실제로 따라해보면 아는 사람들에겐 쉽지만 모르는 사람들에겐 이게 도통 뭐하는 소리인지...하는 느낌이 많이 들어감

일단 Github이 사용하기 편하게 되어있으니 Github의 기준으로 보자면 Github for window에 포함되어있는 어플리케이션도 도움이 된다고 생각. Visual Studio에 깔리는 Git 관리도구도 좋다고 생각하는데 이 경우는 merge할때의 변경내역 충돌 문제도 나름대로 대처가 가능하니

물론 콘솔을 쓰면 더 잘 될 수도 있는것으로 보이지만 난 아직도 콘솔로 충돌해결을 성공해본적이 없다...애초에 CUI랑은 인연이 멀기도 하고. 친해져야 하긴하겠지만

분명 저 위 두개의 툴로는 자유롭게 못 다루는 기능들이 있기때문에 콘솔은 필수적이라고 생각. 하지만 기초적으로 branch나 add,commit은 굳이 콘솔을 쓰지않고도 사용이 가능하고 좀 더 다가가기 쉽다고 생각하기때문에 이쪽으로 접근을 시작하는것도 좋다고 생각함

Add와 Commit

add는 변경내역을 추가하는것이고 commit은 변경내역을 확실하게 history에 고정한다는 개념으로 이해

add된 내역은 변경이 가능하지만 commit된 기록은 변경이 불가한것으로 알고있음. 물론 이걸 revert하거나 수동으로 다시 수정하는 방법도 있긴하지만 몇번 시도해본 결과 이런 수단에 의지하지 않게 되는것이 바람직...

큰 작업을 할때는 branch를 별도로 나누거나 신중하게 commit하는게 중요하다고 생각. commit된 내역을 push하게 되면 서버에 올라가게 되고 Github의 경우 private가 아닌경우 온 인터넷에 공개되게 되는것.

commit를 할때는 위에도 언급했지만 신중하게. 코멘트를 적을때도 명료하게 적는것이 중요하다고 생각. 일단 자기 혼자 본다고 생각하고 modify나 fix등으로 도배해도면 나중에 필요해서 보게 되도 이게 왜 이렇게 수정했는지 감이 잘 안올때가 있음.

특히 git의 경우에는 협업을 위한 도구라고 알고있으므로 로컬에서 작업한다고 해도 기본적으로 남들도 알 수 있는 설명을 첨부하는 버릇을 가지는것이 좋다고 생각

Branch

말 그대로 가지라고 생각하는게 바람직. 나는 비슷하지만 확연하게 다른 프로젝트 두개를 병행으로 운영하기 귀찮아서 branch를 쓰고있긴하지만 남들과 협업할땐 꽤 핵심적인 기능이라고 생각.

branch를 나누게 되면 해당 시점에서 동일한 branch가 두개가 생기는것. 보통 master브랜치에서 나눠서 작업을 하고 하위에서 상위 브랜치로 병합하는것이 일반적으로 보임.

무언가 기능을 추가할때 branch를 따로 만들어 해당 branch에서 작업하고 그 내역을 master로 병합해서 변경내역을 적용하는게 가능.

그냥 기본 브랜치에서 작업하는것에도 무리는 없지만 간혹 기능 추가작업을 하다가 방향성이 틀렸거나 누군가가 해당기능을 보다 좋게 작업을 완료해서 싱크시켰던가 하는 경우에는 꽤나 곤란해짐.

간단한 수정정도는 기본 브랜치에서 하는것도 나쁘지 않다고 보지만 특정 기능을 추가한다고 할때, 혹은 대량으로 내용을 수정하거나 할때는 branch를 나누는것이 좋다고 봄

https://git-scm.com/book/ko/v1/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0

해당 페이지가 상당히 유용

Github 사용법의 경우 Github를 키워드로 넣으면 꽤 나오지만 기본적인 사용법 및 개념은 해당 페이지에서 많이 습득