This is a series of articles related to Source Control or Version Control issues, from a stand-alone app, such as MS SourceSafe, to a Server app, such as MS TFS (Team Foundation Server), to web services such as GitHub, AWS, and MS Azure DevOps. We have tried to categorize this series of articles as Source Control or Version Control, but this site does not have these categories. So, we put the articles in the DevOps category, as explained in the Wiki:
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.[1] DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology.
The structure of this article series will cover:
- Stand Alone App:
- Server App
- MS TFS (Team Foundation Server)
- Online (Cloud) Centralized Service:
- MS Azure: DevOps
- Boards
- Repos
- Pipelines
- Test Plans
- Artifacts
- GitHub
- AWS GitHub Enterprise
- Distributed App:
Because these are huge topics, I will not go step by step. Instead, each section will be relatively independent and will become a reading unit.
- Source Control (1), MS Source Safe --- Stand Alone App
- Source Control (2), MS TFS --- Centralized Server App
- Source Control (3), MS Azure DevOps (GitHub, Jira) --- Centralized Service
- Source Control (4), Git --- Distributed App
- Source Control (4-1), Git --- Configuration
- Source Control (4-2), Git --- Configured to Connect to DevOps and GitHub
- Source Control (4-3), Git --- Cherry Pick in Visual Studio
- Source Control (4-4), Git --- Recover Git Tree: Reflog/Reset
- Source Control (4-5), Git --- Recover Deleted Branch
- Source Control (4-6), Git --- Revert
- Source Control (4.7), Git --- Get Specific Version or Commit
- Source Control (4.8), Git --- Get Specific Version or Commit in practice
- Source Control (4.9), Git --- Merge: Fetch, Pull, Push and Sync --- this article
- Source Control (5), GitHub access (setup connection)
- Source Control (6), DevOps access (setup connection)
- Source Control (7), GitLab access (setup connection and Clone to Local)
- Source Control (8), Git, Azure Repos, and Visual Studio (Interaction)
- Source Control (9), Push into Git Hub and DevOps
- Source Control (10), Git Hub, DevOps Publish
Introduction
In Source Control (2-2), TFS --- Merge, we discussed Merge for TFS. Now, in this article, we will discuss Merge for DevOps or Git.
Why we discuss these two in parallell, because they have similar features, but different, which make people to confuse in one hand and can make people to have a better understanding on the other hand, TFS is a Client/Server app, the Client is just a interface to access server, while DevOps is on cloud --- server, its local copy, Git, is not just a client interface, but is a real and different application.
For Git, Fetch, Pull, Push and Sync are basic features, but sometimes quite confusing. We will compare it with the TFS merge process in order for us to make better understanding.
Git Fetch, Pull, Push, and Sync
Visual Studio 2022 Git menu includes the following options:
- Fetch
- Pull
- Push
- Sync (Pull then Push)
In the Git Changes window, there are four button controls with the same features; from left to right, the button controls include Fetch, Pull, Push, and Sync.
Additionally, there's also an ellipsis (...) button control for additional operations in a context menu that fine-tunes the fetch, pull, push, and sync operations.
- Fetch: from origin to local
- Pull: from origin to local
- Push: from local to origin
- Sync: (Pull then Push)
Compared to TFS Merge
We start from the TFS Merge process, as we discussed In Source Control (2-2), TFS --- Merge, includes the following major processes:
- Get the Latest Versions for both Main and Local
- Merge from Main to Local
- Merge from Local to Main
In TFS, before the merge, we should get the latest version for both Main and Local; for Git, before pull or push, we absolutely should commit all changes in local. Otherwise, we cannot say, pull
The same is true for the push.
Then in TFS, we merge from server to local in order to avoid conflict; that is exactly what we do in Git as PULL, pull is pulling from origin (server) to local.
In the next step, in TFS, we merge from local to server, while in Git, we PUSH --- pushing from local to origin (server).
The FETCH feature TFS does not have, for Git: Fetching checks if there are any remote commits that you should incorporate into your local changes.
When you fetch a branch, the Git Changes window has an indicator under the branch drop-down, which displays the number of unpulled commits from the remote branch (90 incomings in the graph below). This indicator also shows you the number of unpushed local commits (4 outcomings).
The indicator also functions as a link to take you to the commit history of that branch in the Git Repository window. The top of the history now displays the details of these incoming and outgoing commits. From here, you can also decide to Pull or Push the commits.
Finally, SYNC is simply to both pull then push sequentially.
Pull Request and Merge Request
A Git pull request is essentially the same as a Git merge request. Both requests achieve the same result: merging a developer’s branch with the project’s master or main branch. Their difference lies in which site they are used; GitHub (DevOps) uses the Git pull request, and GitLab uses the Git merge request.
Step1. Although (GitHub DevOps) Pull Request is equivalent to (GitLab) Merge Request, the server-side Pull Request is not equivalent to Client-side Git Pull.
- Git pull --- pulling from origin to local
- (GitHub, DevOps) Pull Request --- pulling from Development to Main
Step 2. When we use Visual Studio as a client to push to GitLab,
It seems we cannot trigger create a pull request, as what we do when saving into GitHub or DevOps.
Step 3. GitLab uses Merge Request in the server side.
Make a New Merge Request is created from the server.
Reference