Common Git scripts

Introduction

This blogpost is a collection of common scripts I use very often when I am working with Git. It just are some scripts for later use as reminder for me and off course you can use these too. Now, a nice overview of the different statuses is given by Jianping Zeng. Actually there five statuses. He states about five statuses :  modified, staged, committed, origin and pushed.

Let's see if we can make some examples that handles a couple of these statuses. 

This blogpost assumes that you have created a git repo in Azure Devops.

Starting from scratch 

To create a new repo, you can use the git init command in a folder. It is a command that you can execute once. a hidden git folder structure (.git) is into place and a main branch is created.

git init

Resulting in a message : Initialized empty Git repository in <folder>

Starting with a clone of a repository

The first step with working with repositories is setting your name and email, next is initializeing the directory, the next step is to clone your newly created repository from Azure DevOps to your local computer. From your repository page on Azure DevOps, click on the "Clone" button. Click the button "Clone" or download, and in the “Clone with HTTPs” section, copy the URL for your repository. Next open command shell in windows and execute.

git clone <repo>

This command will result in :

Cloning into '<repo>'...

warning: You appear to have cloned an empty repository.

Add a file to local repository

I've create a small text file in the directory where I've cloned the repository. With git status I'm able to retrieve the status of the local repository. It states that I've included a file but it is not part of the tracking because the file is in the so called working directory of git. 

> git status

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        file1.txt

nothing added to commit but untracked files present (use "git add" to track)

Next step is to add the file to staging area of git. Adding the files to the staging area is executed with the git add command.

I use the following command quite a lot. There are different variations possible of this command.

> git add .

No result message is returned. With git status it is possible to see more about the status of the file.

> git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   file1.txt

The file is now present in the staging area.

Committing changes to the local repository

The next step is adding the code into the local repository. This can be done with the commit command with git commit -m "message". This command will transfer the file from the staging area into the local repository.

This is the command :

> git commit -m "this is a message"
[master (root-commit) 5d395d4] new file
 1 file changed, 2 insertions(+)
 create mode 100644 file1.txt

Let's see what the command git status returns.

> git status

On branch master
Your branch is based on 'origin/master', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)

nothing to commit, working tree clean

Pushing the files to the remote repository

The next step to get the code in the remote repository is to push the code with the git push command. The command pick ups the files from the local repository and puts them in the remote repository.

Execute the following command.

> git push
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 227 bytes | 227.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Analyzing objects... (3/3) (5 ms)
remote: Storing packfile... done (484 ms)
remote: Storing index... done (109 ms)
To https://xxxxxx.visualstudio.com/GitFundamentals/_git/GitFundamentals
 * [new branch]      master -> master

Getting more information with git log

With git log it is possible to get more information about the changes that have been executed. In the dump below.

> git log
commit 5d395d43b890a38e8507db1d03caf33f2865833a (HEAD -> master, origin/master)
Author: Hennie de Nooijer <xxxx@xxxx.com>
Date:   Sun Feb 7 20:53:18 2021 +0100

    new file

Pulling changes from a remote repository (soft)

The next step is getting the changes from the remote repository with the git pull command. I've changed something on the remote repository. I've added an extra line to the file : Second line.

After a changein the file in Azure DevOps, it's possible to execute the git pull command. This will pull the code from the remote repository to my local repository.

And this is the result when the git pull command is executed:

>git pull
remote: Azure Repos
remote: Found 3 objects to send. (24 ms)
Unpacking objects: 100% (3/3), 249 bytes | 22.00 KiB/s, done.
From https://xxxxxx.visualstudio.com/GitFundamentals/_git/GitFundamentals
   5d395d4..22f8f5e  master     -> origin/master
Updating 5d395d4..22f8f5e
Fast-forward
 file1.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Fetching and merging from a remote repository

The problem with a pull is that the changes are merged into your local code and perhaps you want to look into the code that others have created. That's what you can do with git fetch. The code is fetched into the origin repository, you can inspect the code and then decide to merge the code from the remote branch into your local branch.

For this experiment I've changed the file in the git repo in Azure Devops once again. I've added a third line to the file. 

Now let's see what happens when git fetch is executed?

>git fetch
remote: Azure Repos
remote: Found 3 objects to send. (27 ms)
Unpacking objects: 100% (3/3), 257 bytes | 16.00 KiB/s, done.
From https://bifuture.visualstudio.com/GitFundamentals/_git/GitFundamentals
   22f8f5e..0f49d2d  master     -> origin/master

Now the idea is that you want to check out the changes that your colleague has done. So if you execute a merge command it will merge the code into your local branch. With git checkout you can checkout the fetched remote branch.

>git checkout origin/master
Note: switching to 'origin/master'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 0f49d2d Updated file1.txt

The commit is the same hash. I can now inspect the file :

So, now I can decide to merge this file into my local branch. I think I'm going to accept this. First switch back to my local main branch and issue a merge.

>git checkout master
Previous HEAD position was 0f49d2d Updated file1.txt
Switched to branch 'master'
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Now merge the remote branch with the local branch. 

>git merge
Updating 22f8f5e..0f49d2d
Fast-forward
 file1.txt | 1 +
 1 file changed, 1 insertion(+)

And now I've the data in my local main branch.

The result of git status :

>git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

The result of git log :

>git log
commit 0f49d2d98fb3ba98af4590bb6e9e8315ffb6d699 (HEAD -> master, origin/master)
Author: hennie de nooijer <hdenooijer@hotmail.com>
Date:   Wed Feb 10 18:57:45 2021 +0000

    Updated file1.txt

commit 22f8f5e01ab41ffd57765f050699e6361b2f1350
Author: hennie de nooijer <hdenooijer@hotmail.com>
Date:   Sun Feb 7 20:17:11 2021 +0000

    Updated file1.txt

commit 5d395d43b890a38e8507db1d03caf33f2865833a
Author: Hennie de Nooijer <hdenooijer@gmail.com>
Date:   Sun Feb 7 20:53:18 2021 +0100

    new file

List of common git commands:

I've included a couple of the git commands.

Initializing a folder (.git directories)                             git init

Set email and username                                                     git config

Log of a branch's commits                                             git log

Current branch and files in working area or staging.     git status

Bring in changes but still merge with local branch     git fetch

A remote repository to clone locally                             git clone <url repo>

Bringing in changes locally and merging immediately     git pull

Sending changes to remote repository                             git push

Adding changes to working area                                     git add .

Adding changes to the staging area                             git commit -m “description”

Restore a modified file in the working area                     git restore <file>

Restore file to working area                                             git restore <naam bestand>

Differences between working directory and commit     git diff

Final thoughts

This blogpost is an introduction into Git commands. I've explained the details and provided a list of common git commands. Enjoy.

Hennie

Using the Snowflake Python connector in a YAML pipeline

Introduction

If you want to use the snowflake python connector in your pipeline you have to install the connector software on a agent. If you have a private agent it's only necessary once but on a public agent you need to install the software every time. If you don't do that, you will get an error in python :

ImportError: No module named snowflake.connector

##[error]The process '/usr/bin/python' failed with exit code 1

Installation

Installation of the Python connector in a YAML pipeline is fairly easy. There are a couple of steps :

• Upgrade pip to the latest version.
• Download the python connector.
• Installation of the python connector.

Here is the script:

- script : | 
    python --version
    python -m pip install --upgrade pip
    python -m pip install -r https://raw.githubusercontent.com/snowflakedb/snowflake-connector-python/v2.3.7/tested_requirements/requirements_36.reqs
    python -m pip install snowflake-connector-python==2.1.3
  displayName: 'Install Snowflake connector'

This will download the software on the machine and you can use the connector in your python script.

Final thoughts

It was a bit of a surprise how simple it was to include this in my YAML pipeline. Now I can use the Snowflake python connector in my python scripts. Maybe that is for a future blogpost!

Hennie

Introduction to GIT

Introduction

Today, a quick introduction in Git. In this blogpost a couple of familiar Git commands will pass and I will demonstrate the commands in small demos.

Installation

But first download the software of Git to your local machine and install the software locally. Verify the installation by using the following command : "Git version". This will return the current version of Git. 

git version

In my case this results in the following version 2.28.0.

Demo

For this blogpost I created a folder with some files and I will experiment with these files : FileA, FileB and FileC.

And in every file I inserted the following phrase. This is and example for File A:

This is File A

Initialize the repository

When the file are there, the first statement that needs execution is Git init. This command creates an empty Git repository (basically a .git directory with subdirectories for objects, refs/heads, refs/tags, and template files. An initial HEAD file that references the HEAD of the master branch is also created.

Git init

A message appears when the initialization is ready. 

Running git init in an existing repository is safe. It will not overwrite things that are already there. The primary reason for rerunning git init is to pick up newly added templates.

Add the files to the repository

With git add you can add the files to the l(local) repository. It typically adds the current content of existing paths as a whole. This command updates the staging area (index) using the current content.

git add .

And now the files are added to the staging area. The git status command displays the state of the working directory and the staging area. It lets you see which changes have been staged, and which haven’t, and which files aren’t being tracked by Git. The Git status output does not show you any information regarding the committed project history. For this, you need to use git log.

git status

Here the result of the git status. The files are in the staging area but they need to be committed.

The "commit" command is used to save your changes to the local repository. Creating a new commit containing the current contents of the index and the given log message describing the changes. The new commit is a direct child of HEAD, and the branch is updated to point to it,

git commit -m "new files"

Here the result of the commit of the files.

Now let's check the commit with "git status".

git status

So what have we done so far? We have added the files from the working directory to the staging area (aka index) with the "git add" command and with "git commit" we added the files from the staging area to repository.

Check this out with the "git log" command.

git log

Change the file

Now let's edit the file FileA with some changes.

Save it and check the status with "git status".

git status

Git status reports that FileA is changed and these changes are not added and commit to the repository.

Let's add the file to the staging area with "git add".

git add FileA.txt
git status

"Git status" reports that the file is changed and add to the staging are, now. But they need a commit to the repository.

So, let's commit the changed to the repository with the "git commit" command.

git commit -m "FileA is changed"
git status
git log

And here is the result of the "git log". There are now two commits and HEAD is poinitng to the master. 

The next step is changing fileC and add this file to the repository.

Execute the following commands and see the results. One command I haven't explained yet is git diff. From the Git site : "Show changes between the working tree and the index or a tree, changes between the index and a tree, changes between two trees, changes resulting from a merge, changes between two blob objects, or changes between two files on disk".

git status
git diff
git add FileC.txt
git commit -m "FileC- Changed"
git log

And now there are three commits and changes

It is also possible to go back one (or more) version of the code. You can execute this with
"git checkout" command.

git checkout b81a42d23c48657dc976372d989a09e9cb6022ed

And now the original file is back.

git log

It's not possible to see the successors of the commits with "git log", now. Now let's go back to the last changes 

git checkout b81a42d23c48657dc976372d989a09e9cb6022ed

And now the last commit file is back

And with "git log" we see that we are back on the latest commit of the master branch.

git log

Used resources 

For this blogpost I've used the following resources :

• Git

Final Thoughts

This is a small introduction to git. 

Hennie

DevOps series : Working with teams in a data warehouse : ownership (part II)

Introduction

This blogpost is a successor of the blogpost "DevOps series : Working with teams in a data warehouse (part I)". In order to control the changes of the objects in a large data warehouse environment with multiple teams, one of the first steps you have to take is to define ownership. Who is the owner of that object? Because if all teams are responsible for the objects, no one is responsible for the objects. Sometimes there is some implicit knowledge who is responsible, and perhaps consultations happens between teams, but it will quickly grow out of hand when the number of teams grow. Therefore, to get control over de objects, teams need clear understanding and take ownership and responsibility for the objects for which they feel and are responsible.

Vertical and horizontal teams 

Teams can be organized in different ways; teams can be responsible for a vertical solution, for instance, from source to dashboard or teams are responsible for a horizontal layer, eg. the data warehouse layer. A mix is also possible: sometimes teams build a data warehouse for it's own information products (eg. dashboards) and later on, other teams build dashboards on top of these data objects.

I've made a distinction between the different parts (I call them modules) of a data warehouse : sources (delivery), Data ware house, and information products. Examples of a source (delivery) are extraction code, data lake, file copy code and staging objects. For your data ware house, think about raw vault, business vault and datamarts. There is a lot of discussion (in my current role)  about raw vault, because hub and links are more business driven but the sats from the different sources are more source driven. We discussed some scenarios like a source vault solution and an integration layer for integrating the BK's and the links. Although there is a lot of resistance from Dan Linstedt and others as well, for source vaults but you can make your deployments independent from other teams with this approach. And in order to compensate the source vault approach an integration layer can be adopted. Other options are possible as well. Next, the information products, these are more end user delivery oriented and think about components like SQL views for the cube or report, cubes (Tabular model) and dashboards (PowerBI). With this approach, teams are more independent and can deliver their code much faster to production.

Now, the preferred team pattern in my opinion is team pattern number 1. This team pattern is responsible to process the data from source to dashboard.The team is able to deliver data from start to end. It is not (or less) dependable on the work of other teams. This is also in line of a DevOps Team. The team is able to deliver stand-alone products to the business.

Although, the other patterns are less preferable, these can happen too. For instance, team pattern 3 happens sometimes when a management dashboard is needed and retrieves the data from all kind of different areas of a company, eg finance, HR, Sales, etc. Because of this reason it's not feasable to create a team that is responsible from source to end. So this creates the need for a team that is dependent on the work of other teams.

Team pattern 2 is an example of a horizontal team and this pattern occurs a lot in companies. It's very common to organize teams in cost efficient ways in order to utilize resources as efficient as possible. Although it seems logical to do this, but this team pattern is not organized around delivering products to the customer but around people. This approach will lead to waiting time. No added value is delivered to the end user until information products are build on top of them (by other teams) and this causes handover moments and inefficiencies.

Final thoughts

This is the second blogpost about working in large data warehouse environments with multiple teams. 

Hennie

DevOps series : Working with teams in a data warehouse (part I)

Introduction

Perhaps, you have been in this situation: imagine the following problem, you have a data warehouse, and it is shared between a large number of teams and you have implemented a version control and a branching strategy like Gitflow or Microsoft flow and you think that you have it all but somehow code is not flowing in cadence into production. Symptoms are that developers are complaining that code breaks because other teams deployed their code too or it's unknown which team is responisble for data objects.

This blogpost is a collection of my experiences at several customers in the last couple of years. I've been working in companies with multiple teams, mostly working with Microsoft technology in data environments. I've been working in DevOps environments where we were working as a team, delivering information products to our customers in the business, together with other teams. This blogpost is a mix of knowledge and experiences of Data-, DevOps- and Lean principles!

Continuous delivery and a data warehouse

We, as data professionals are working in data environments (eg. data warehouses) where we want a common data platform, where entities are well formed designed and structured. We think about the business and we try to model the data according to the processes and the way of working (in a part of) of the company. This will result in a common data model implemented in a database. 

I've seen that multiple teams are working on separate parts of the database, but sometimes teams are dependent on the work of other teams because they use data entitites of other teams. Sometimes there are entities that are hotspots of usage between different teams. Think about entities like Customer, Employee or Organization. These are common used entities in a data warehouse. But there are also entities that are not used by other teams in their part of the data architecture. 

In the example above, Team 3 has dependencies between objects that are maintained by team 1 and 2. This could be an ETL dependency. Now, if one of the teams changes the referenced object, Team 3 has a problem. The ETL logic will result in a 'failure'. This is a very common situation when teams are working in a common data architecture and this is an annoying problem and it is hard to fix.

Final thoughts

What if we could find a way for teams to deliver their code as much as possible independent from the other teams to production and where dependencies are there, can we manage these dependencies? Are there ideas on how solve the ambiquity, who is responsible for what, and can we use methods like branching by abstraction to manage dependencies between teams?

How can we achieve a complete data platform (data warehouse) with the advantages like subject-oriented, integrated, time-variant and non-volatile (Inmon) and deliver your products as fast as possible to the business. Data warehouses had a bad name in the past, and data vault and other flexible techniques helped to deliver faster to the business. An extra challenge is the number of teams that work on a data ware house. How should they balance their priorities between speed of delivery and the integrity of a data warehouse? If they focus on the speed of delivery, less attention is paid to the integrity and the other way around focus (only) on the integrity, less and less is delivered to the business. Off course integrity of the data warehouse is important, but delivering code to production is as important as well.

This is the first blogpost about DevOps and lean principles and working in data environments like data warehouses. I'm planning to write more about this topic in the future. 

Hennie

Generating SSH accessing Azure DevOps with DBeaver

Introduction

For access from Dbeaver to Git I used a PAT key before, but I heard that SSH is a better secured way to access Azure DevOps/Git, therefore I investigated the usage and implementation SSH access to Azure Devops. This blogpost is a walkthrough the process.

Generating the SSH key

First, generate a key with the tool 'ssh-keygen' by opening a CMD window. Enter the following command in the box.

D:\>ssh-keygen -C "hennie.denooijer@xxxx.nl"
Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\hdeno/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\hdeno/.ssh/id_rsa.
Your public key has been saved in C:\Users\hdeno/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:LtBYadsfaSDFSDFSFDAY90qnea5MXLOJKs5giLlmFHXs hennie.denooijer@xxxx.nl
The key's randomart image is:
+---[RSA 2048]----+
| ...     .o++o.  |
|.  ...    o=*.   |
| . ooo.  . o..   |
|. o.++E   o      |
| o oo.. S+ . .   |
|  + ..... + o o  |
| +   ...+. . + . |
|o . .  = o. = .  |
| o.. .o o. . o   |
+----[SHA256]-----+

This command produces the two keys needed for SSH authentication, your private key (id_rsa) and the public key (id_rsa.pub). Never share the private key! Here is the content of the id_rsa.pub file that default is stored in the folder : C:\Users\{user}\.ssh (I changed some characters):

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDGhi6uphRGsgfWvlnckcpqEMGevUuS1iDoUx645965m
621qoCheJbaPtzVP4ldwVKU8dRtileWkMGjwYjRej0TWXSk4NouooctXGmZIrBy95ZDK6fkmXJEyIWvxO
581+C/qhPxTD+Nmsac2+yXB123D+s2Ky7wsKNFPg2RZ1VrW0RRgoegGCJqfT1EmL0D44R2yWggbTlDcL
E11K/trlGbxCcoAc/TP8YDGB+PLeV4qEqciJasasaaaLhWD72Mnj8M2ar5213wwdItSQlC4Di0sO792
J4RbtLlyBbFCrqNt9nnLIxj8BzWLZBsD7qISa1FYqh5jwpRlRpmuDLDdLRd hennie.denooijer@xxxx.nl

Add the SSH key to Azure Devops

The next step is to add the key to Azure Devops. Goto settings and click on the SSH Public keys. 

Then, Press on + New key to enter a new key to Azure DevOps.

Initially I thought that I could copy the fingerprint string that was generated from the ssh-gen tool. I copied that into the Public Key Data box, but that resulted in an error.

Here is the error :

An error occurred while adding the xxx key: Invalid key: Key must be Base64 encoded with OpenSSH format and RSA type. Valid keys will start with "ssh-rsa".

After some reading of the Microsoft documentation I understand that I have to use the key that is stored in the id_rsa.pub. Copy that in the Public Key Data box.

It is also possible to test whether the SH working by issueing the command ssh -T

D:\Git\SF_PERFTEST_TPC_H_MODULEA>ssh -T git@ssh.dev.azure.com
Warning: Permanently added the RSA host key for IP address 'xx.74.xx.1' to the list of known hosts.
Enter passphrase for key 'C:\Users\hdeno/.ssh/id_rsa':
remote: Shell access is not supported.
shell request failed on channel 0

Microsoft Documentation states the following : "Test the connection by running the following command: ssh -T git@ssh.dev.azure.com. If everything is working correctly, you'll receive a response which says: remote: Shell access is not supported." Be careful : NOT supported. If this is the paraphrase then it is ok.

Using the SSH key in DBeaver

The next step is trying to use the SSH key in DBeaver and here I made a mistake by trying to use the https uri.

After trying some couple of times, reading the documentation, some helpful information from collegaes, I found I had to set the git remote url with the command Git command set-url and I used the sam url as I used with https. 

git remote set-url origin git@ssh.dev.azure.com:v3/xxxx/xxx/_git/SF_PERFTEST_TPC_H_MODULEA

But, that resulted in an error.

Warning: Permanently added the RSA host key for IP address 'xx.xx.xx.103' to the list of known hosts.
remote: Expected _full or _optimized, not '_git'.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I changed the uri a bit (I removed _git from the uri). Better is to copy the SSH string from Azure DevOps.

git remote set-url origin git@ssh.dev.azure.com:v3/xxx/xxxx/SF_PERFTEST_TPC_H_MODULEA

Then when I try to check in with the tool DBeaver the following window appeared and here I had to enter the paraphrase that I entered before, during the creation of the SSH key. 

And here it is. I'v DevOPs/Git integration with DBeaver, based on SSH key.

Final thoughts

A small howto blog on creating a SSH key for accessing Azure DevOps from a tool like DBeaver.

Azure DevOps and Git integration with DBeaver

Introduction

One of the nice things about working with software is that there is always something new to explore. Now, I'm looking into the possibillities of DBeaver and the integration with Git. The reason is that I want to explore connecting Snowflake and DBeaver/Git for my (local) development environment. This way I have version controlled code locally and I can deploy the code to Snowflake. I have a richer GUI instead of the webbased editor of Snowflake itself. But, it's experiment with DBeaver and Git to learn how it works and whether it is usable for projects I'm involved.

Git plug-in

Now it seems that Git is not fully integrated into DBeaver but you have to install a plugin into DBeaver to have Git integration. Now it was kind of puzzle but I managed to install the plugin. Here is the walkthrough. 

There seems to be more Git plugins, one of Dbeaver itself and one Eclipse and it seems that the Eclipse plugin is breaking the Dbeaver code, but as you may see later in this blogpost, when I select the DBBeaver Git support a couple of Eclipse code is installed. Not sure whether this is the right one. 

Configure

Let's walkthrough the steps I took in order to make it work. A small disclaimer, I'm not stating that I executed the most efficient steps to configure the setup with Git, DBeaver, DevOps. May be there is a better sequence of steps to perform the configuration. Try out yourself. 

1. First start DBeaver, select "Help" and then select "Install New Software".

This will open the install new software window. 

2. In the next step a window opens and here you can choose the repository. I chose the DBeaver Git integration. 

3. When you are done, press the Next button and an overview window is presented. Here you can see that some Git software of Eclipse is installed, also.

4. Click on Next and the next screen is shown. Here you have to review the licenses and accept the licenses.

5. Press on finish when the licenses are reviewed and then a warning appears that authenticy can not be established. 

6. DBeaver is restarted and it appears again. When DBeaver returns nothing seems really changed, when you look closer there are some elements added in the File menu

And below on the screen an extra pane appeared. 

7. Press on the "Create a new local Git repository" and enter a directory name for Git in a folder. In my case it is D:\tmp\git.

Git

8. Now go to your Git folder and start CMD.exe and write the following statements.

I saved the script "Script.sql" that I have created in this folder and with Git status I'm notified that the file is untracked.

9. The next step is to add the file to the local git repository with "Git add". 

10. After the "Git add" execute a "git commit" as you can see in the following screenshot. 

11. Next set up the remote repository Url with Git Remote command.

Next, when I try to push the code to the remote repository, I recieved the following error message because the remote repository contains work that I haven't included in my local repository. It seems that Git thinks that I 'm mixing up repositories.

"Git Pull" gave me a "Fatal" because of unrelated histories. 

Now, I have created a local repository and a remote repository and I commited some code to the repositories and Git doesn't seems to understand how the two projects are related. The error is resolved by toggling the allow-unrelated-histories switch. After a git pull or git merge command, add the following tag: git pull origin master --allow-unrelated-histories

12. Enter "git pull origin master --allow-unrelated-histories".

13. Change something in the code and check if the configuration of Git is correctly done.

14. Commit and push the code to the remote repository. 

Okay, that seems to be working well.

DBeaver

But why did I need to install the Plugin in DBeaver? I configured Git but I didn't use any functionality of the Git plug-in in DBeaver. Let's take a closer look at DBeaver and the Git plug in. 

15. Now in the projects pane there is a little icon, and if you look closely it says "Git". Press on the icon with your mouse.

16. Select the "Existing local repository" and press Next.

17. Select the folder where the Git repository resides. In my case D:\tmp\Git.

18. Choose "Import using the New Project Wizard" and press on Finish.

19. And now a new project is created in DBeaver with the script.sql file in the project.

20. One step is to check whether the code is commited from DBeaver. I Changed something in the code and committed the code the remote repository

21. In the File menu, Choose Git and then "Commit changes to Git"

22. And in the next window press the button "commit and push" to push the changed code to the remote repository. 

23. For the login, create a PAT in Azure Devops and use that as a password with your user account. Press log in.

24. And the code is pushed to the remote repository. Press Close to close the window.

25. And voila! The change is commited into Git and Azure DevOps shows this perfectly.

Final Thoughts

This blogpost is about building a develpoment environment with Git, Azure DevOps and DBeaver. I learned something new and hopefully it can help you too.

Hennie