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

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

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