0

I have read some of the details here

Git Push Explanation

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

Dave
  • 33
  • 6
  • When you say Sprint-1 was "copied" from main, do you mean you made the Sprint-1 branch off of main? – Schwern Nov 09 '22 at 01:22
  • yes, that's right, created a branch called Sprint-1 off main (which I believe in some repo they call 'origin'? – Dave Nov 09 '22 at 01:57
  • "main" is local. Everything you do in Git is local except push, pull, and fetch. "origin" is a copy of the repo you cloned from (not a full copy, just the differences from your repo) presumably the DevOps one. See [Working with Remotes](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes) for more. – Schwern Nov 09 '22 at 02:18
  • we actually have a "main" branch under "remotes/origin". Then we have "sprints" folder which contained "sprints[number]", but I'm thinking those sprints were cloned from main right after the end of each sprint... – Dave Nov 09 '22 at 04:16
  • Since your local is a clone of the remote, *both your local and remote will have a main branch*. origin/main is a "remote tracking branch"; it remembers where main was on the origin remote (ie. DevOps) the last time Git looked. This tracking branch is necessary because *Git does not talk to the network* aside from a few commands like pull, push, and fetch. When you say you have a "sprints folder" where is this folder? – Schwern Nov 09 '22 at 17:43
  • The Sprints folder is in remote/origin. So I would normally check it out, then a copy will be created in my local, then from that local copy I would branch off to work on a task, staged the changes and commit and push. – Dave Nov 09 '22 at 21:36
  • By "check it out" do you mean `git clone` or do you mean `git checkout`? – Schwern Nov 09 '22 at 22:22
  • "Check it out" - I use VS, right-click on the branch and select Checkout. I don't use DevOps for checking out or cloning. I use GIT Repository window in Visual Studio. – Dave Nov 10 '22 at 03:03
  • It's hard to tell exactly what your IDE is doing, I'd suggest using the command line for a little bit to learn. That said, thinking about checkout as creating a copy isn't quite right. It's better to say it updates your working copy (the files you work on) to match how things were at that commit. If only a few files were changed, it will only update those files. – Schwern Nov 10 '22 at 18:27

1 Answers1

0

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
Schwern
  • 153,029
  • 25
  • 195
  • 336
  • Thank you for a wonderful illustration. What actually confused me was thinking DevOps contains ALL of the code and NOT the copy, so based on on your explanation, there is the 'base' source that DevOps points to, and that DevOps only contains a COPY of that. Initially I thought what's the point of PR approval when the code is already sent and merged to the 'base' repo (which I initially thought DevOps is). So in summary, there's the 'base' repo, the DevOps copy, and the local copy. cheers! – Dave Nov 09 '22 at 04:13
  • @Dave "*there's the 'base' repo, the DevOps copy, and the local copy*" No, there is just the DevOps repo and your local repo (and anybody else's clones). When you cloned DevOps you got a copy of the DevOps repo. Pushing and pulling keeps them in sync. "*What actually confused me was thinking DevOps contains ALL of the code and NOT the copy*" DevOps does contain all of the code. "*Initially I thought what's the point of PR approval when the code is already sent and merged to the 'base' repo*" The code is not merged until the PR is approved. (Unless your setup is particularly strange) – Schwern Nov 09 '22 at 17:48
  • Okay, if DevOps contain all of the code, where is the code changes sitting when committed and pushed from VS, pending PR approval? Surely there's a repo there somewhere that houses the code with changes prior to merging with DevOps base repo? Thanks – Dave Nov 09 '22 at 21:33
  • @Dave The code changes are in a branch in the DevOps repo. When you push your branch it is uploaded and copied into the DevOps repo as a branch of the same name. When the PR is approved, the DevOps copy of your branch is merged. So if you push your local Sprint-1 branch, your code is in a Sprint-1 branch in the DevOps repo. – Schwern Nov 09 '22 at 22:31