Git Commit Staged and Push and Visual Studio, what actually happens?-CodePudding

I have read some of the details here

but I still don't quite understand where the code is actually sitting if not in the remote branch after 'PUSH'ing.

My scenario is, I have a local sprint branch named 'Sprint-1' taken from the same remote branch. That remote branch was copied from 'main' branch.

Using VS2022, I made the change locally, staged, then chose 'Commit Staged and Push'. In DevOps, I created a PULL REQUEST. My understanding is, that change must be sitting somewhere, NOT YET merged, pending Approval from the admin. If it is not merged yet, where is the change sitting in DevOps?

So it's then MERGED only when that pull request is approved and I clicked COMPLETED in devops, right? Or am wrong in my assumption?

Thanks

CodePudding user response：

tl;dr: Your work is in a branch called Sprint-1 on DevOps' copy of the repository.

My scenario is, I have a local sprint branch named 'Sprint-1' taken from the same remote branch. That remote branch was copied from 'main' branch.

Thinking of a branch as a "copy" isn't right, and will muddle your thinking. Instead, a branch is just a label on a commit.

For example, let's say your main branch has three commits: A, B, and C.

A - B - C [main]

The main branch is just a label "main" that points at commit C.

Now you make your Sprint-1 branch off main. What happens? Git adds a new label "Sprint-1" also pointing at C.

$ git branch Sprint-1

A - B - C [main]
          [Sprint-1]

That's it.

Using VS2022, I made the change locally, staged, then chose 'Commit Staged and Push'. In DevOps, I created a PULL REQUEST. My understanding is, that change must be sitting somewhere, NOT YET merged, pending Approval from the admin. If it is not merged yet, where is the change sitting in DevOps?

You have a complete copy of the repository, and DevOps also has a complete copy of the repository. When you push, you upload your changes to the DevOps copy of the repository. By default, this repo is referred to as "origin" as in "the original repository you cloned your repository from".

Pushing uploads your commits to DevOps. Your changes are sitting in a branch called Sprint-1 in DevOps' copy of the repository.

Let's go back to our example repository just after you made your branch. We'll also include what the devops copy of the repo looks like.

devops
A - B - C [main]

local
A - B - C [main]
          [Sprint-1]

We're going to commit and push separately for illustration. You should also get into the habit of committing and pushing separately. Think of "commit" as saving your work and "push" as ~~inflicting your work on~~ sharing your work with others; don't push until you're ready to share your work.

You make a commit locally.

devops
A - B - C [main]

local
$ git commit -a
A - B - C [main]
         \
          1 [Sprint-1]

Then push your changes to devops. This also pushes the new branch label.

devops
A - B - C [main]
         \
          1 [Sprint-1]

local
$ git push
A - B - C [main]
         \
          1 [Sprint-1]

And there you go. When the PR is accepted, the branch is merged and then deleted.

devops
A - B - C -- M [main]
         \ /
          1

local
A - B - C [main]
         \
          1 [Sprint-1]

Then you pull (download) that merged code into your own repository...

devops
A - B - C -- M [main]
         \ /
          1

local
$ git pull
A - B - C - M [main]
         \ /
          1 [Sprint-1]

And delete your local branch.

devops
A - B - C -- M [main]
         \ /
          1

local
$ git branch -d Sprint-1
A - B - C - M [main]
         \ /
          1