Software Development with Git

This article covers the Software development with Git in which helps the developer to start working on their own branch which is a copy of the production branch. This article will include merge, rebase, the concept of branching, tagging, and remotes

Git is an Open Source Distributed Version Control System. Now that’s a lot of words to define Git.

Let’s break it down and explain the wording:

• Control System: This basically means that Git is a content tracker. So, Git can be used to store content — it is mostly used to store code due to the other features it provides.
• Version Control System: The code which is stored in Git keeps changing as more code is added. Also, many developers can add code in parallel. So, Version Control System helps in handling this by maintaining a history of what changes have happened. Also, Git provides features like branches and merges.
• Distributed Version Control System: Git has a remote repository which is stored in a server and a local repository which is stored in the computer of each developer. This means that the code is not just stored in a central server, but the full copy of the code is present in all the developers’ computers. Git is a Distributed Version Control System since the code is present in every developer’s computer.

Single Release Development Strategy

A software team working on one release at a time follows the following steps:

Everyone should take the latest updates from the production branch daily using the merge or rebase Git commands.

Now let’s discuss more merge or rebase

Git Merge

Merging is a common practice for developers using version control systems. Whether branches are created for testing, bug fixes, or other reasons, merging commits changes to another location. To be more specific, merging takes the contents of a source branch and integrates them with a target branch. In this process, only the target branch is changed. The source branch history remains the same.

Git Rebase

Rebasing is the process of moving or combining a sequence of commits to a new base commit. Rebasing is most useful and easily visualized in the context of a feature branching workflow.

Many developers have confusion in a commit, merge and rebase let’s clear in the diagram below:

Hope you will get a clear idea about the commit, merge and rebase.

Working on branches

Let’s say you are working on “product-release-dev1” and you have to pull the latest changes from “product-release1.” This will make sure any changes that were moved to the release branch are available in the local feature branch. This also avoids conflicts or duplicate code while merging the feature branch to the release branch at feature completion time.

Before doing this step, you should be only on your feature branch. Use the “git branch” command to verify the branch name before doing a merge.

Now you have done some changes on “product-release-dev1”, and you want  to push that changes to “product-release1” then you need to commit that changes to your local git and then push it to “product-release-dev1” and generate a pull request for “product-release1” then the authorized person will review that changes and merge your code in “product-release1” brach

Now, create a tag from the release branch to the testing team for validation of the feature. We must provide a tag to the testing team upon completion related features to be tested.

Next, delete the feature branch upon completion of the feature and delete the release branch upon completion of the release.

Any post-production release fix can be done in a tag. Remember to move the code to the master and post any production fix release.

This command creates a new branch, “product-release1_prodfixticketNumber,” from the production release tag “product-release1_tag1.”

Create the next release branch from the master, as the master has the production code, and follow the same approach for development as described above.

Working with Remotes

To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. In this section, we’ll cover some of these remote-management skills.

Add a New Remote to your Git Repo

To add a new remote, use the git remote add command on the terminal, in the directory your repository is stored at.

The git remote add command takes two arguments:

A remote name, for example, “Upstream”

A remote URL, which you can find on the Source sub-tab of your Git repo

For more details visit: Connect Click2Cloud:

• Email us – contact@click2cloud.net

• See website – https://www.click2cloud.com/

• Watch our videos : https://www.click2cloud.com/videos-page.php?watch=24

•  https://www.click2cloud.com/videos.php

• Past Events: https://www.click2cloud.com/past-events/past-events.php

• Codefest 2021: https://www.click2cloud.com/codefest/

• Read our Blog's – https://www.click2cloud.com/blogs.php

• Follow us on Twitter– https://twitter.com/click2cloudinc

• Find us on LinkedIn – https://www.linkedin.com/company/click2cloud-inc-

• Subscribe on YouTube – https://www.youtube.com/channel/UCjVgly_5QMuNZQh2I2FkHQQ

Summary

Development with git includes much more than we have covered. Git is a distributed revision control system and is very useful to support software development workflows. The ‘. git’ directory on every machine is a full repository which has full version tracking capabilities and independent of network access. You can maintain branches, perform merges, and continue with development even when you are not connected to the network.

This approach works fine for projects where a team is working on a single release at a time. Most teams are working on multiple releases at a time, so they have to maintain more than one release branch active at a time.