From 071aef87a710f67040d359e46bd77dd79b7d92b6 Mon Sep 17 00:00:00 2001 From: IvanYuriev2 <104007307+IvanYuriev2@users.noreply.github.com> Date: Wed, 31 Jul 2024 15:55:49 +0200 Subject: [PATCH 1/3] Update forks.md Public doc has an incorrect description of what the Forks in Azure DevOps are. It is not a full copy of the upstream repo, it is based on upstream repo and fully depends on it. So, need to correct that detail to avoid confusion of the end-client. --- docs/repos/git/forks.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/repos/git/forks.md b/docs/repos/git/forks.md index 159b3a111e6..8ed1eb2beb2 100644 --- a/docs/repos/git/forks.md +++ b/docs/repos/git/forks.md @@ -15,9 +15,9 @@ ms.subservice: azure-devops-repos-git [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)] [!INCLUDE [version-vs-gt-eq-2019](../../includes/version-vs-gt-eq-2019.md)] -Git repo forks are useful when people want to make experimental, risky, or confidential changes to a codebase, but those changes need to be isolated from the codebase in the original repo. A new fork is basically a clone of the original repo pushed to a new remote repo. The fork is independent of the original repo, and is a complete copy unless you specify a single branch. +Git repo forks are useful when people want to make experimental, risky, or concealed changes to a codebase, but those changes need to be isolated from the codebase in the original repo. A new fork is basically a new remote repo that shares the source code of the original repo. -As an independent copy, changes you make to your fork, such as adding commits or branches, aren't shared with the original repo. If you want to merge your codebase changes into the original repo, you must create a [pull request](pull-requests.md) (PR) to request review and approval of those changes. +As an independent copy, changes you make to your fork, such as adding commits or branches, are hidden from the original repo. If you want to merge your codebase changes into the original repo, you must create a [pull request](pull-requests.md) (PR) to request review and approval of those changes. The forking process doesn't transfer any permissions, policies, or build pipelines from the original repo to your fork. @@ -123,7 +123,7 @@ git remote set-url upstream ## Push local changes to your fork -When you fork, you create a personal and independent copy of the remote repo. So, there's nothing to prevent you from working directly in the `main` branch of the local clone and then pushing that work to the `main` branch of your fork. However, it's generally better to use [feature branches](git-branching-guidance.md#use-feature-branches-for-your-work) for your work. By using feature branches: +When you fork, you create a personal and isolated copy of the remote repo. So, there's nothing to prevent you from working directly in the `main` branch of the local clone and then pushing that work to the `main` branch of your fork. However, it's generally better to use [feature branches](git-branching-guidance.md#use-feature-branches-for-your-work) for your work. By using feature branches: - You can maintain multiple, independent workstreams simultaneously. From d3bdf753f340f70c44e5b4fc8f87ee23827678d1 Mon Sep 17 00:00:00 2001 From: IvanYuriev2 <104007307+IvanYuriev2@users.noreply.github.com> Date: Wed, 14 Aug 2024 13:10:08 +0200 Subject: [PATCH 2/3] more accurate description of the fork based on the real implementation and the concept --- docs/repos/git/forks.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/repos/git/forks.md b/docs/repos/git/forks.md index 8ed1eb2beb2..5693a14b086 100644 --- a/docs/repos/git/forks.md +++ b/docs/repos/git/forks.md @@ -17,7 +17,7 @@ ms.subservice: azure-devops-repos-git Git repo forks are useful when people want to make experimental, risky, or concealed changes to a codebase, but those changes need to be isolated from the codebase in the original repo. A new fork is basically a new remote repo that shares the source code of the original repo. -As an independent copy, changes you make to your fork, such as adding commits or branches, are hidden from the original repo. If you want to merge your codebase changes into the original repo, you must create a [pull request](pull-requests.md) (PR) to request review and approval of those changes. +As an independent version, changes you make to your fork, such as adding commits or branches, are hidden from the original repo. If you want to merge your codebase changes into the original repo, you must create a [pull request](pull-requests.md) (PR) to request review and approval of those changes. The forking process doesn't transfer any permissions, policies, or build pipelines from the original repo to your fork. @@ -123,7 +123,7 @@ git remote set-url upstream ## Push local changes to your fork -When you fork, you create a personal and isolated copy of the remote repo. So, there's nothing to prevent you from working directly in the `main` branch of the local clone and then pushing that work to the `main` branch of your fork. However, it's generally better to use [feature branches](git-branching-guidance.md#use-feature-branches-for-your-work) for your work. By using feature branches: +When you fork, you create a personal version of the original repository ("upstream"). This version is independent of the original, though it shares the code and retains a link to the original repository, allowing for future synchronization. So, there's nothing to prevent you from working directly in the `main` branch of the local clone and then pushing that work to the `main` branch of your fork. However, it's generally better to use [feature branches](git-branching-guidance.md#use-feature-branches-for-your-work) for your work. By using feature branches: - You can maintain multiple, independent workstreams simultaneously. From caab25361251d69fd5bca81fee382b642bf2351a Mon Sep 17 00:00:00 2001 From: IvanYuriev2 <104007307+IvanYuriev2@users.noreply.github.com> Date: Wed, 14 Aug 2024 15:47:24 +0200 Subject: [PATCH 3/3] Update forks.md typos fixed and few more words added to describe "upstream" --- docs/repos/git/forks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/repos/git/forks.md b/docs/repos/git/forks.md index 5693a14b086..19f1f49c9c1 100644 --- a/docs/repos/git/forks.md +++ b/docs/repos/git/forks.md @@ -123,7 +123,7 @@ git remote set-url upstream ## Push local changes to your fork -When you fork, you create a personal version of the original repository ("upstream"). This version is independent of the original, though it shares the code and retains a link to the original repository, allowing for future synchronization. So, there's nothing to prevent you from working directly in the `main` branch of the local clone and then pushing that work to the `main` branch of your fork. However, it's generally better to use [feature branches](git-branching-guidance.md#use-feature-branches-for-your-work) for your work. By using feature branches: +When you fork, you create a personal version of the original repository (original repository is referred as "upstream"). Fork is independent from the upstream, but fork shares the code and retains a link to the upstream, allowing for future synchronization. So, there's nothing to prevent you from working directly in the `main` branch of the local clone and then pushing that work to the `main` branch of your fork. However, it's generally better to use [feature branches](git-branching-guidance.md#use-feature-branches-for-your-work) for your work. By using feature branches: - You can maintain multiple, independent workstreams simultaneously.