Git Branching Strategies

     A Git branching strategy is a set of guidelines that defines how branches should be created, named, and managed in a Git repository to ensure a smooth and organized development workflow. The goal is to make it easier to collaborate with multiple developers, track features, and release code efficiently while avoiding conflicts and managing different stages of development (e.g., new features, bug fixes, and production-ready code). 

Here are some common Git branching strategies: 

• Trunk-Based Development Strategy 
• Feature-based strategy 
• Gitflow strategy 

• Trunk-Based Development Strategy

     In trunk-based development, developers work directly in the main branch (often called trunk). Instead of maintaining multiple long-lived branches, developers focus on small, incremental changes and frequent merges to the main branch. This strategy promotes continuous integration and rapid deployment. 

• main or trunk: This is the only active branch. Developers create very short-lived feature branches or work directly on main, making small, frequent commits. 

Workflow: 

1. Developers work on small features and commit changes directly to main. 
2. Feature branches are short-lived (often only a few hours or days), reducing merge conflicts. 
3. Continuous integration tools automatically build and test changes. 

•  Feature-based strategy

Feature branching is a simple branching strategy where each new feature is developed on its own branch. This approach allows for isolated development and testing of features, making it easier to roll back changes if necessary. Feature branches are created off the master branch, and when the feature is complete, it is merged back into the master branch. 

Feature branching is a great option for smaller projects or teams that want a straightforward branching strategy. 

1. main (or master): Contains production-ready code. 
2. Environment branches or Develop branch: These branches represent different stages of deployment, such as staging, production, or testing. 
3. Feature branches: Work is done on individual feature branches, which are merged into environment branch (or develop branch) for testing and deployment. 

Workflow: 

1. Feature branches are created from the main or staging branch (or develop). 
2. After development, the feature branch is merged into an environment or develop branch for testing. 
3. Once tested, the code is merged into main (production). 

 

• Gitflow branching strategy 

Gitflow is a popular branching strategy that uses two main branches: master and develop. 

The master branch contains production-ready code, while the develop branch contains the latest development code. Feature branches are created off the develop branch, and when the feature is complete, it is merged back into the develop branch. When the develop branch is ready for release, it is merged into the master branch, and a new release is created. 

Gitflow is a robust branching strategy that works well for large projects with long release cycles, but it can be complicated to set up and maintain. It also requires strict discipline around feature branch creation and merging. 

Workflow: 

1. Start with develop for ongoing development. 
2. Create feature branches for new functionality. 
3. Merge feature branches into develop when completed. 
4. Use release branches for preparing stable versions. 
5. Fix critical issues on hotfix branches and merge back into both master and develop. 

Thank you.

How to Push an Existing Project to GitHub

         In daily basis developer work is to do code check in, check out, pull, fetch and so on. But in the current post, we will learn how to push the existing local project to GitHub repository.

For example:- I have a project EmployeeManagement(EMS) in my local but no one can able to access or modify code without creating and pushing code to GitHub repository.

The steps to push local project to GitHub repository as follows,

1) Create a repository on GitHub.

Create a GitHub account if you don't have.
Then Go to Account --> Your  repositories 
Click on New as shown in below screenshot. 

Github New Repo Creation

When click on New button, will open Create New Repository page.

Create Repository

Provide repository name(Usually project name)

Select public or private repository option

     To avoid errors, do not initialize the new repository with README, 
license, or gitignore files. You can add these files after your project has been pushed to GitHub.
Click on Button/action ""Create repository"

2) Initialize the local directory as a Git repository.

    Change the current working directory to your local project and then initialize the local directory as a git repository using command "git init"

e.g your project directory is C:\\ProjectRepo\EMS
then 

C:\ProjectRepo\EMS>git init

3) Add the files in your new local repository(using git add command). This stages them for the first commit.

Add files to the GitHub,

C:\ProjectRepo\EMS>git add .

If you want to add each file, then use git add "file path" 

C:\ProjectRepo\EMS>git add "file path to add to git"

# Adds the files in the local repository and stages them for commit. To unstage a file, use 'git reset HEAD YOUR-FILE'.


4) Commit the files that you've staged in your local repository.

Use command -  git commit -m "First commit" to commit the added file to gitHub.

C:\ProjectRepo\EMS>git commit -m "First commit"

5) At the top of your GitHub repository's Quick Setup page, click  to copy the remote repository URL.

Copy below HTTPS or SSH Project URL

Remote Repo HTTPS o SSH URL

         

    In the Command prompt, add the URL for the remote repository where your local repository will be pushed.
>git remote add origin "remote repository URL"

C:\ProjectRepo\EMS>git remote add origin "remote repo HTTPS or SSH URL"

6) Push the changes in your local repository to GitHub.

 Using git push command, you can the committed files to the remote repository as follow,

C:\ProjectRepo\EMS>git push origin master

master - is the branch name.


Related Post:--
Permission denied(publickey), fatal:couldn't read from remote repository - Gihub Error

Permission denied(publickey), fatal:couldn't read from remote repository - Gihub Error

        In the current post, we will check one of the gihub error while accessing the private repository code. I faced this issue recently when I try to access(git clone) private repository without adding ssh key into git-hub account.

The error message is,

C://WS/repo> git clone "URL Of PrivateRepo"

Permission denied (publickey).
fatal: Could not read from remote repository.

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

This means that GitHub is not able to authenticate you. There are two reasons,

1) You might not set up with a SSH key .  OR
2) Your generated SSH key is not associated with GitHub account.

First, we need to create SSH key to access the private Repository.

• Create new SSH Key:-

 Open terminal of any directory, and type below command.  

$ ssh-keygen -t rsa -b 4096 -C "type your email here"

After enter the above command, then need to enter file name  to save the ssh key, by default it should save in the home directory of ssh folder.

Generating public/private rsa key pair.
Enter file in which to save the key (/home/administrator/.ssh/id_rsa):

Then enter the passphrase, or leave as it is just enter,

Enter passphrase (empty for no passphrase): [Type a passphrase]

After running all above commands, the SSH key will generate and it will save mentioned directory.

dir/id_rsa  , dir/id_rsa.pub

Copy the contents from id_rsa.pub file, and key should start with ssh-rsa,
and you can add into github account.

• Add generated SSH key to GitHub account:--

Login to your GitHub account using basic credentials, i.e username/email and password.

Then go to Setting -> SSH and GPG keys 

Click on New SSH Key,

Give key title, then add the generated key in the text box, key should start with ssh-rsa or ssh-dss or above mentioned text.
click on Add SSH key. It will add into the GitHub account.

Enable the key as follows,

If you follow above steps properly, then you can able to access the code of private Repository.

Any doubt or clarifications, please put comment in the comment section.

Thank you......