gitflow?? workflow?? 뭔데??

1. gitflow / workflow 협업

• 나는 지금까지 협업을 해본적 없으니, 줄곧 브랜치 master에만 push를 해왔다.

• 혼자 쓸때에는 브랜치 한곳에만 작업을 했었다.

• master 브랜치는 프로덕션에 배포할 준비가 된 상태만 올린다.
• master 브랜치 나온 dev 브랜치에서 개발을 한다.

• 브랜치를 만들면, 브랜치를 땄다고 표현한다.
• 명령어에서 -b를 붙이면 없는 브랜치를 딴다.
• -b를 붙이지 않으면 없는 브랜치를 만든다.
• 중요한 것은, 커밋한 상태에서 브랜치를 변경하면, 그 파일은 커밋한 브랜치안에서만 저장되기 때문에 다른 브랜치에서는 파일이 달라진다.
• 어떤 브랜치에서 땄냐에 따라 그 파일이 있는지 없는지가 달라진다!!! 어디서 땄는지가 중요하다!

2. hotfix 브랜치

• 긴급한 에러를 고치기 위해 만드는 브랜치이다. 이 브랜치는 master 브랜치에서 바로 만들어서 프로덕션에서 생긴 이슈를 고치고, master브랜치로 합쳐서 배포할 수 있게 한다.

3. feature / release 브랜치

• feature 브랜치를 만들어 기능적인 것들만 여기 브랜치에 푸시를 한다. 그후에 다시 dev 브랜치에 푸시를 해준다.
• release 브랜치는 개발자들의 암묵적인 룰이 있는데, 여기서는 기능들은 추가하지 않고 버그만 수정해서 업데이트 한다!! 그후에 결과물은 master브랜치에 푸시를 한다.

4. forking-repository

• 팀장님께 pr을 받고 통과가 되면 merge를 한다.
• merge는 레파지토리를 합치는 과정이다.
• 회사레파지토리에서 develop브랜치에 merge한것을 푸시하면, 우리는 pull develop을 하면 다른 사람들이 만들어 놓은 기능까지 추가 되어 받을 수 있다.
• 위 과정들을 rotate해서 반복적으로 걸쳐 master브랜치에 푸시하는 작업을 'forking-repository'라고 한다.

• 나는 항상 git push origin master 이렇게 사용해 왔었다.
• 예를 들어, git push origin feature-boardwrite 이렇게 이제부터는 push할 브랜치와 주소를 잘보고 푸시를 해야한다.
• pull을 할때에는 git pull upstream develop 이런식으로 pull을 하여야 한다.
• 위의 명령어는 예시이니, 자기가 사용하는 레파지토리를 보고 응용해야겠다!