안녕하세요. 질문을 올립니다.

 

github을 거의 처음사용하고 있습니다.

 

origin은 로컬, master는 웹상의 master를 가르키기 때문에,

 

git pull origin master 또는 

git push origin master라는 명령을 사용하면, origin(로컬)에서 파일을 master(웹 레파지토리)로 전송시킨다. 이렇게 알고 있습니다.

 

만약, 로컬의 경로를 바꿀 경우, git init을 해도 master에 올라간 파일과 비교는 안되는 것이죠?

 

항상 동일 폴더에서 git init한 것을 다시 확인 하면서, 비교하는 것이 맞는 것이죠?

 

파일명은 같고, 일부수정한 웹개발 폴더를 올리는데, git init을 한다고해도, 전의 git init을 가르키는 것이 아니라서, 동기화나, merge같은 것이 안되는 것 같은데.. 그럼, 항상, 같은 폴더에서 올려야하는 것이맞겠네요?

 

설명 부탁드립니다.

 

TAG •
  • profile
    origin은로컬이 아닙니다.
    원격저장소서버이름이에요..

    기본적으로많이쓰는 이름이 origin이에요
  • profile ?
    git init
    git add *
    git remote add origin [git웹경로]
    정말 로컬이 아니더라도, 결국 origin은 자신의 컴퓨터의 저장소를 가르키잖아요. 그래서 로컬이라는 표현을 써봤습니다.
  • ? profile
    로컬이라고하면 아에 리모트가 선언되어있지 않아요. 그냥 그컴퓨터에서 git 서버를 돌린다고해도 로컬이라는개념과는틀립니다.. 그래서 알려드리는거에요
  • profile
    설명이 이해가잘안가요 git init는 비교할때 쓰는것이 아니에요.
    첫폴더에 이폴더를 깃으로쓰겠다고 선언하는거에요 파일변경확인은 다릅니다
  • profile ?

    네. 그래서, 깃으로 선언하겠다고 하고, 파일을 올리고, 다음번에는 전 경로와 다른 곳에 폴더를 만들고, git init을 선언할 경우, 파일이나 구조가 거의 같다고 하더라도, git이 인식을 못한다. 이말을 하고 싶어서요. 그래서, 항상, 동일한 곳(git init을 처음에 한곳 밖에 못함;비교가 안되어서.)에서, 파일을 올려야한다. 이것이 맞는 것같아서 질문 올려봤습니다. 조언을 구하고 싶어서요. 거의 실시간 답변이네요. 답변 감사합니다.

  • ? profile
    두개의 폴더에서 비교하지는 않아요
    해당내부에 있는 파일의 변경점만 확인하는방식이에요
  • profile ?

    답변감사합니다. 아직 제가 미숙해서 github사용을 더 해봐야할 것 같네요.

  • profile
    git push origin master 는 origin 서버의 master 브랜치에 업로드한다는 뜻이에요.
    만약에
    git remote add myserver [git웹경로] 라고 한다면
    git push myserver master 라고 쓰면 되요.
  • profile ?

    답변 감사합니다. origin이란 것의 경우는 결국 remote명령 다음에 것의 이름일 뿐이라는 것이네요. 그럼, git init을 했던 폴더가 아닌 다른 곳에서 git init을 하고 push를 하려고 한다고 해도, 동일 파일이라도  init이 다르기 때문에 안되는 것 아닌가.  git init을 하면 해당 경로에 숨김폴더가 생기더라구요. 이것을 알고 싶어서, 질문올렸습니다.

  • profile

    git init: 이제부터 이 폴더를 git 저장소로 사용하겠다 (최초 1회만 실행)
    git remote add origin <경로>: 이제부터 <경로>에 있는 서버를 origin이라고 칭하겠다 (최초 1회만 실행)
      - 동기화할 경로를 매번 입력하려면 완전 귀찮잖아요. 그래서 별명을 지정하는 것입니다.
      - 별명 지정 이외의 의미는 없습니다. 이 명령 실행만으로 동기화가 이루어지지도 않습니다.
    git push origin master: origin 서버에 있는 master 브랜치를 현재 폴더의 내용으로 덮어씌운다
    git pull origin master: 현재 폴더의 내용을 origin 서버에 있는 master 브랜치의 내용으로 덮어씌운다

    push와 pull의 차이는 동기화를 어떤 방향으로 하느냐의 차이이고,
    덮어씌워지는 쪽에 그 사이 변화가 있었다면 에러메시지를 뿜으며 실패하게 됩니다.
    (변화가 있는 상태에서 동기화하려면 merge나 rebase를 사용해야 합니다.)

     

    서버가 1개밖에 없는 경우 origin이라고 칭하는 것이 관례입니다.

    관례를 따르기 싫다면 꼭 origin이라고 할 필요는 없습니다.

    2개 이상의 서버와 동기화하는 경우에는 목적에 맞게 remote를 여러 개 추가하여 사용합니다.

    예를 들어 저는 라이믹스 공식 깃허브, XE 공식 깃허브, 제 계정의 라이믹스 사본, 제 계정의 XE 사본

    이렇게 4개의 서버와 정기적으로 동기화해야 하기 때문에

    remote를 4개 추가해 놓고 필요에 따라 push하거나 pull하며 사용합니다.

  • profile ?

    답변 감사합니다. github에 대해서 많이 알아가네요.

    이제, github의 master에다가, 파일을 업데이트를 시킬 수 있게 되었습니다.

     

    pull이나 fetch의 경우, push하기전에, master에 올릴 origin파일들과 이미 있는 master파일들을 동기화하기 위해 해야하는 과정이라고 알고 있습니다. 그 동기화과정을 거쳐서 git이 비교를 할 수 있게 만든다음, push로 master에 파일을 업데이트시킨다. 저는 이런 방식으로 사용하고 있네요.

     

     master는 단지 파일을 받는 쪽. 결코 origin으로 다시 보내지는 않는 걸로 사용하고 있습니다. 꼭 master에 있는 파일을 origin이 받아야 한다면, 한개씩 github에서 긁어서 사용하고 있습니다.(지금 제가 쓰는 방식으로 한다면, readme.md파일에서 그런 상황이 발생하는 것 같습니다.)  꼭 master의 파일들이 필요할 경우, 따로 폴더를 생성한다음, clone으로 다운받고, git init을 걸어놓은 폴더에 해당 파일 붙여넣기. 저는 지금 이런 방식으로 사용하고 있네요. 

     

     merge나 rebase같은 경우는 branch를 생성해서 만든 경우, branch끼리의 비교. 이렇게 되는 것같게 생각하고 있습니다. 혹시 답변 또 다시고 싶으면 달아주세요. 안다셔도 괜찮습니다. 너무 많은 질문을 한 것같아서요.

  • ? profile

    브랜치 사용 패턴은 프로젝트의 성격과 규모에 따라 다릅니다. 일단 기본 브랜치를 master라고 부르는 것이 관례이지만, 이걸 지워버리고 다른 브랜치를 써도 아무 탈이 없어요. 깃허브에서도 기본 브랜치를 master가 아닌 다른 것으로 자유롭게 변경할 수 있고요.

    XE처럼 master 사용을 최소화하는 프로젝트가 있는가 하면, 소규모 프로젝트들은 master에서 모든 작업을 다 처리하기도 합니다. (깃허브에서 pull request를 넣으면 기본 브랜치로 들어가기 때문에 어쩔 수 없이 master의 활동량이 늘어나기도 합니다.) 대규모 프로젝트인데도 master를 마구 쓰다가 새 버전을 발표할 때가 되면 해당 버전을 위한 브랜치를 따로 만들어서 안정화시키는 역발상도 있어요.

    어떤 방식을 사용하더라도 동일한 프로젝트를 2개 이상의 폴더에 각각 clone해 놓고 사용하거나, git에서 제공하는 push, pull, fetch, merge, rebase, stash, cherry-pick 등의 기능을 사용하지 않고 수동으로 파일을 복붙한다면 뭔가 잘못하고 계신 거라고 봅니다. 리눅스 커널처럼 전세계에 흩어진 수백 명의 개발자가 수천 가지의 다른 작업을 동시에 하고 있어도 git에서 제공하는 기능만으로 서로의 수정 내역을 공유할 수 있도록 한다는 것이 git의 존재이유인데, 이걸 활용하지 않고 계시니까요.

    특히 cvs나 svn에서 git으로 오시는 분들이 흔히 범하는 실수는 브랜치 생성을 꺼리는 것입니다. 기존의 버전관리 시스템들과 달리 git에서는 브랜치 생성이 매우 쉽고, 브랜치마다 폴더를 따로 만들어 쓸 필요도 없고, 웬만한 작업은 모두 브랜치간의 상호작용이라는 형태로 처리가 됩니다. 브랜치 만들고 합치고 지우는 것을 두려워하지 말아야 합니다. 2개 이상의 clone으로 작업하고 계시다면 2개 이상의 브랜치를 활용하는 방식으로 바꿔보세요.

    예를 들어 깃허브에 다른 사람이 내 맘에 드는 pull request를 등록했어요. 이걸 내 로컬 저장소에 당장 적용해 보려면 어떻게 해야 할까요? pull request에 해당하는 브랜치(pull/1234/head)를 찾아서 내 저장소의 새 브랜치로 fetch하고, 새 브랜치를 checkout하거나 해당 커밋들만 다른 브랜치로 merge, rebase, 또는 cherry-pick하여 가져오면 됩니다. pull request에 해당하는 저장소를 따로 clone할 필요도 없고, 수정내역을 직접 복붙할 필요도 없어요. 모두 하나의 저장소 내에서 브랜치간의 상호작용으로 처리가 됩니다.

  • profile ?

    답변 감사합니다. 브렌치를 빼내고 merge, rebase와 같은 작업. 설명하신 부분들을 생각은 해보고 있습니다만, 지금으로서는 master에 pull을 사용해서 동기화 시킨뒤, 일부 수정된 파일들만 push로 올리면 별다른 문제가 없는 것 같아요. 사용법을 잘 알아야하는데 말이죠.

     브렌치가 많아지면, 뭔가 풍성해질것 같다는 생각도 듭니다. 브렌치끼리 merge나 rebase를 하면서 말이죠. 데이터베이스(MySql)이 들어가는데, 없는 버젼으로 브렌치로 만들어서 한번 올리면 좋을 것 같다. 이런 생각도 해보네요. 일반사람들 중에, database까지 설치하지 않겠다. 이런 사람도 있을테구요.
    댓글을 보고서, 다른 사람의 github를 내 저장소로 가져와서 브랜치로 만든다음, 혼자 고쳐보고 만든 다음, 보여주는 것도 재밌겠다. 이런 생각도 드네요. 시간 있을 때에 댓글 읽어봐야겠네요. 감으로는 대충알겠는데 말이죠. 실제로 해볼 때가 있거나, 또 다른 사람 github을 저장하거나 할 때 쓸 것 같다는 생각이 듭니다.