Git 포크는 실제로 Git 클론입니까?

Git 포크는 실제로 Git 클론입니까?

---

나는 사람들이 Git에서 코드를 포크한다고 계속 들었습니다. Git "fork"는 Git "clone"과 함께 미래의 병합을 포기하려는 심리적 의지를 더한 것처럼 의심스럽게 들립니다. Git에는 포크 명령이 없습니다.

GitHub는 서신을 스테이플 링하여 포크를 좀 더 현실적으로 만듭니다. 즉, 포크 버튼을 누르고 나중에 풀 요청 버튼을 누르면 시스템이 소유자에게 이메일을 보낼 수있을만큼 똑똑합니다. 따라서 저장소 소유권 및 권한에 대한 약간의 춤입니다.

예 아니오? 이 방향으로 Git을 확장하는 GitHub에 대한 불안? 아니면 Git이 기능을 흡수한다는 소문이 있습니까?

---

GitHub 컨텍스트에서 Fork 는 Git을 확장하지 않습니다.
서버 측에서만 복제 할 수 있습니다.

로컬 워크 스테이션에서 GitHub 저장소를 복제 할 때 명시 적으로 "기여자"로 선언하지 않는 한 업스트림 저장소에 다시 기여할 수 없습니다. 클론이 해당 프로젝트의 별도 인스턴스이기 때문입니다. 프로젝트에 기여하고 싶다면 다음과 같이 포크를 사용하여 할 수 있습니다.

• GitHub 계정에서 해당 GitHub 저장소를 복제합니다 (즉, "fork"부분 , 서버 측의 복제본).
• 해당 GitHub 저장소에 커밋을 제공합니다 (자신의 GitHub 계정에 있으므로 푸시 할 모든 권한이 있음).
• 원래 GitHub 저장소에 대한 흥미로운 기여를 다시 알립니다 (즉, 자체 GitHub 저장소에서 변경 한 내용을 통해 "pull 요청"부분 ).

" Collaborative GitHub Workflow " 도 확인하십시오 .

원본 저장소 (업스트림이라고도 함)와의 링크를 유지하려면 해당 원본 저장소를 참조하는 원격을 추가해야합니다.
" GitHub에서 원본과 업스트림의 차이점은 무엇입니까? "를 참조하십시오.

그리고 Git 2.20 (2018 년 4 분기) 이상에서는 델타 아일랜드를 사용 하여 포크에서 가져 오는 것이 더 효율적 입니다.

---

나는 사람들이 git에서 코드를 포크한다고 계속 듣는다. Git "fork"는 git "clone"과 미래의 병합을 포기하려는 심리적 의지를 더한 것처럼 의심스럽게 들립니다. git에는 fork 명령이 없습니다.

"포킹"은 버전 제어 시스템에서 특별히 지원하는 명령이 아니라 개념입니다.

The simplest kind of forking is synonymous with branching. Every time you create a branch, regardless of your VCS, you've "forked". These forks are usually pretty easy to merge back together.

The kind of fork you're talking about, where a separate party takes a complete copy of the code and walks away, necessarily happens outside the VCS in a centralized system like Subversion. A distributed VCS like Git has much better support for forking the entire codebase and effectively starting a new project.

Git (not GitHub) natively supports "forking" an entire repo (ie, cloning it) in a couple of ways:

• when you clone, a remote called origin is created for you
• by default all the branches in the clone will track their origin equivalents
• fetching and merging changes from the original project you forked from is trivially easy

Git makes contributing changes back to the source of the fork as simple as asking someone from the original project to pull from you, or requesting write access to push changes back yourself. This is the part that GitHub makes easier, and standardizes.

Any angst over Github extending git in this direction? Or any rumors of git absorbing the functionality?

There is no angst because your assumption is wrong. GitHub "extends" the forking functionality of Git with a nice GUI and a standardized way of issuing pull requests, but it doesn't add the functionality to Git. The concept of full-repo-forking is baked right into distributed version control at a fundamental level. You could abandon GitHub at any point and still continue to push/pull projects you've "forked".

---

Yes, fork is a clone. It emerged because, you cannot push to others' copies without their permission. They make a copy of it for you (fork), where you will have write permission as well.

In the future if the actual owner or others users with a fork like your changes they can pull it back to their own repository. Alternatively you can send them a "pull-request".

---

"Fork" in this context means "Make a copy of their code so that I can add my own modifications". There's not much else to say. Every clone is essentially a fork, and it's up to the original to decide whether to pull the changes from the fork.

---

Cloning involves making a copy of the git repository to a local machine, while forking is cloning the repository into another repository. Cloning is for personal use only (although future merges may occur), but with forking you are copying and opening a new possible project path

---

I think fork is a copy of other repository but with your account modification. for example, if you directly clone other repository locally, the remote object origin is still using the account who you clone from. You can't commit and contribute your code. It is just a pure copy of codes. Otherwise, If you fork a repository, it will clone the repo with the update of your account setting in you github account. And then cloning the repo in the context of your account, you can commit your codes.

---

Forking is done when you decide to contribute to some project. You would make a copy of the entire project along with its history logs. This copy is made entirely in your repository and once you make these changes, you issue a pull request. Now its up-to the owner of the source to accept your pull request and incorporate the changes into the original code.

Git clone is an actual command that allows users to get a copy of the source. git clone [URL] This should create a copy of [URL] in your own local repository.

---

Apart from the fact that cloning is from server to your machine and forking is making a copy on the server itself, an important difference is that when we clone, we actually get all the branches, labels, etc.

But when we fork, we actually only get the current files in the master branch, nothing other than that. This means we don't get the other branches, etc.

Hence if you have to merge something back to the original repository, it is a inter-repository merge and will definitely need higher privileges.

Fork is not a command in Git; it is just a concept which GitHub implements. Remember Git was designed to work in peer-to-peer environment without the need to synchronize stuff with any master copy. The server is just another peer, but we look at it as a master copy.

---

There is a misunderstanding here with respect to what a "fork" is. A fork is in fact nothing more than a set of per-user branches. When you push to a fork you actually do push to the original repository, because that is the ONLY repository.

You can try this out by pushing to a fork, noting the commit and then going to the original repository and using the commit ID, you'll see that the commit is "in" the original repository.

This makes a lot of sense, but it is far from obvious (I only discovered this accidentally recently).

When John forks repository SuperProject what seems to actually happen is that all branches in the source repository are replicated with a name like "John.master", "John.new_gui_project", etc.

GitHub "hides" the "John." from us and gives us the illusion we have our own "copy" of the repository on GitHub, but we don't and nor is one even needed.

So my fork's branch "master" is actually named "Korporal.master", but the GitHub UI never reveals this, showing me only "master".

This is pretty much what I think goes on under the hood anyway based on stuff I've been doing recently and when you ponder it, is very good design.

For this reason I think it would be very easy for Microsoft to implement Git forks in their Visual Studio Team Services offering.

---

In simplest terms,

리포지토리를 포크 한다고하면 기본적으로 GitHub 계정의 GitHub ID로 원본 리포지토리의 복사본을 생성하는 것입니다.

과

저장소를 복제 한다고하면 GitHub 계정에 복사본이 없어도 시스템 (PC / 노트북)에 원본 저장소의 로컬 복사본을 직접 생성하는 것입니다.

참고 URL : https://stackoverflow.com/questions/6286571/are-git-forks-actually-git-clones