깃얘기 나와서 그런데 merge가 나음 rebase가 나음?

[dd(210.90)]

우리 회사 정책 한때 git pull --rebase가 정책이였는데

merge 커밋 안보이게 하라면서

근데 난 rebase할때보다 merge가 뭔가 conflict 같은거 해결하기 더 좋은거같던데

[ㅇㅇㅇ(175.223)]

현대있을때 무조건 리베이스로 한줄 만들더라고. 뭐가 좋고 나쁜지는 의미없짆아 ?

[dd(210.90)]

걍 정책에 따르는게 맞는거겠지..? 근데 난 리베이스가 무서운게 push하려면 -f를 넣어야되잖아. 그러면 운안좋으면 남에꺼 덮을 가능성도 생기는거 아님?

[ㅇㅇㅇ(175.223)]

???????? f를 왜너???

[dd(210.90)]

f안넣으면 푸시 안되지않음?

[dd(210.90)]

아 생각해보니 f넣을 필요가 없었던거네

[dd(210.90)]

언제 한번 튕겨서 f넣은적 잇었던거같은데 생각해보니 그냥 pull 다시 땡겨야되는 상황이였구나

[ㅇㅇㅇ(175.223)]

니가 뭔가 잘못쓰고있는게 확실함. 리베이스로 그런문제가 생길리가 없음 ㅌㅋㅋㅋ

[dd(210.90)]

그러네 ㅅㅂ -f가 필요할리가 없었네 내가 근데 rebase로 컨플릭 해결하는 동안 메인코드에 커밋이 추가로 생기면 rebase끝낸 코드 푸시 못하는 경우는 생기는거 맞지?

[ㅇㅇㅇ(175.223)]

ㅇㅇ 전부 해결하고 올리는거지

[dd(210.90)]

그니깐 누구나 지 꼴리는대로 메인코드에 푸시하는 시스템이면 rebase로 하는게 안좋네 어떻게보면 물론 애초부터 꼴리는대로 푸시할 수 있는게 문제인거같긴하지만

[익명(45.67)]

커밋 히스토리 깔끔하게 가져가려고 그러는거 아니양?

[dd(210.90)]

그런거같긴한데, 메인 코드에 푸시하게 되어있어서 rebase하고나면 -f로 푸시해야되는데, 남에꺼 덮을 수가 있잖슴 하긴 이거부터 잘못된거긴 하구나 ㅋㅋ merge request로 안받고 그냥 다같이 한 브랜치에 푸시하게 되게되어있는데 이게 잘못된거네 ㅋㅋ

[익명(45.67)]

아 pr를 안하고 각자 한다는 거구나; 엄청 위험하지 할듯...;;

[dd(210.90)]

ㅇㅇ pr안하고 각자 알아서 코드 넣는 시스템임 좆소라서 그런듯함 ㅅㅂ 병특 끝나야 여기서 더이상 안썪는건데

[Go(golang970104)]

pussy가 조음 ㅇㅅㅇ