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:
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
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.
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.
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.
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.
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
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.