DEV Community: Satyakoidala

Git Merge vs. Git Rebase: A Beginner's Guide

Satyakoidala — Mon, 23 Sep 2024 07:28:58 +0000

When working with Git, you'll often find yourself merging or rebasing branches. These two commands are similar in that they integrate changes from one branch into another, but they achieve this in different ways. Let's break down the key differences and when to use each.

Git Merge

What it does:

Combines the changes from one branch into another by creating a new commit.

How it works:

Git creates a new commit that represents the combined changes of the two branches.
This new commit is added to the history of the target branch.

When to use it:

When you want to preserve the history of both branches.
When you're merging a feature branch back into the main branch.
When you're resolving conflicts between branches.

Example:

# bash
git checkout main
git merge feature-branch

Git Rebase

What it does:

Replays the commits from one branch onto another, creating a linear history.

How it works:

Git takes the commits from the source branch and replays them onto the target branch, one by one.
If there are conflicts, you'll need to resolve them before continuing.

When to use it:

When you want to keep a clean, linear history.
When you're preparing a feature branch for a pull request.
When you're fixing a bug in an old commit.

Example:

# bash
git checkout feature-branch
git rebase main

Key Differences

Best Practices

Understand the implications:

Before using either command, make sure you understand how it will affect your project's history.

Use rebase for clean history:

If you want a clean, linear history, rebase is often the preferred choice.

Use merge for preserving history:

If you need to preserve the history of both branches, merge is the better option.

Be cautious with rebase:

Rebasing can rewrite history, so be careful when using it on public branches (shared branches).
If you need to undo a rebase, you can use git reflog to find the old commit and reset to it.

Conclusion

By understanding the differences between Git merge and Git rebase, you can choose the right command for your specific use case and maintain a clean and organized Git history.

For a more definitive guide, you can check out this awesome YouTube tutorial which I have found helpful in mastering the concepts.

Thank you! Happy Learning!!

Essential Git Commands: A Developer’s Guide

Satyakoidala — Sun, 21 Apr 2024 12:37:47 +0000

Introduction

Welcome, fellow developers! In today’s post, we’ll delve into the powerful world of Git commands. Whether you’re managing version control, collaborating with a team, or ensuring code integrity, Git remains an indispensable tool in our arsenal.

Setting Up Your Environment

Assuming you have a Git repository hosted remotely (such as on GitHub), let’s explore the essential commands. Here’s the basic structure of your repository:

/origin (remote origin)
   |-- <master/develop/main branch>

Cloning the Repository

To get started, clone the remote repository to your local machine. GitHub provides two secure protocols for this purpose:

HTTPS Protocol: Authenticate using your Git login credentials.
SSH Protocol: Utilize SSH keys for secure authentication.

# Clone the repository
git clone <remote_repository_link>

Creating and Switching Branches

Stay up-to-date with the remote head by creating a local branch that tracks it:

# Create a new local branch
git checkout -b <new_local_branch> <upstream/remote_head_branch>

# Switch to a specific branch
git checkout <branch_name>

# List available branches
git branch

Keeping Your Workspace Fresh

Before starting work, ensure a clean slate by pulling the latest changes from the remote repository:

# Pull changes from the remote
git pull origin <remote_head_branch>

Committing Your Work

As a developer, wrapping up your day with a git commit is a habit. First, stage your changes:

# Add changes to the staging area
git add "<filename1>" "<filename2>"

# Or add all modified files
git add .

Next, commit your changes:

# Commit with a descriptive message
git commit -m "__commit__msg__"

You can stack any number of commits before you push into the remote origin and create a Pull Request (PR).

Pushing to the Remote Repository

When your task is complete, push your commits to the remote repository:

# Push to the remote
git push origin <working_branchname>

It returns a PR-initiating link, you can use it to create your PR.

Undoing a Commit

Mistakes happen! To undo a commit:

# Undo the last commit (or nth last commit)
git reset HEAD~[1,n]

# Keep changes staged while undoing the commit
git reset --soft HEAD~[1,n]

# Delete the entire commit (use with caution)
git reset --hard HEAD~[1,n]

Comparing Different Heads

Git makes it easy to compare commits, branches, or changes. Learn more in this blog.

# Compare the last commit with uncommitted changes
git diff

# Compare a specific file
git diff -- <filename>

# Compare between branches or commits
git diff <name/hash1>..<name/hash2>

Copying Commits with Cherry-Pick

Copying commits from one branch to another is a common task. The git cherry-pick command allows you to selectively apply specific commits to a different branch. Here’s how:

# Make sure you're on the target branch
git checkout <target_branch>

# Cherry-pick the desired commit
git cherry-pick <to_be_copied_commit_hash>

Checking Branch Status

To assess the status of your local branch relative to its upstream (usually the remote head), use:

# Check branch status
git status

Exploring Commit History

Understanding your git commit history is essential. To view the complete log of commits in reverse chronological order, use:

# View commit log
git log

Deleting a Branch

If the branch is no longer needed! Delete it!

# Delete a branch
git branch -D <branchname>

Conclusion

These commands form the backbone of Git usage. While minor syntactic differences may exist across Git versions, mastering these essentials will serve you well throughout your development journey.

Happy coding!

Feel free to customize this guide to suit your specific needs. If you have any questions or need further assistance, don’t hesitate to ask!

CI pipeline for ReactJS apps using GitHub actions

Satyakoidala — Wed, 14 Jun 2023 17:31:20 +0000

Hey folks,

In this post, we will understand and gain knowledge about "How to create basic CI pipeline for your React App using GitHub Actions?".

Prerequisites

Basic understanding of Git & GitHub.
Basic understanding of JSON notation.
Any react application source code made with your efforts🤓. (You can contribute to others code as well 😉)

🧐 Firstly, what are GitHub Actions and what is CI?

To simply put, these are set of actions that are triggered on Git events like push, pull request and are executed in the sequence mentioned through the workflow file.

CI (Continuous Integration) is the process building and testing the code for every commit made on your chosen branches. It ensures that everything in the code is working fine after the commit is merged just like in your local machine.

😯 That's bit too much, now what is the workflow file??

It is the actual file, that is responsible for defining the actions on git events for continuous integration and deployment. You can customize your workflow file to work with any your own personalized CI/CD server deployed on tools like Jenkins, Ansible, Travis CI, etc.

😓😢 Didn't have personalized CI/CD server to serve the CI purpose??

Don't worry my friend! GitHub actions comes to rescue. You don't need to have any personalized CI server anymore. When a workflow file is detected by git, it starts working on with it. Identifying that there is no personalized CI server defined in workflow file, GitHub actions starts deploying machines from its own marketplace and begins running the actions mentioned by you.

Yay!😊 Now that we have got the basic understanding of theory behind our idea. Let's start understanding the workflow file for CI pipeline for react-app.

Follow through your project structure and make necessary changes or adjustments to your workflow file later.
This is my project structure at high-level. Inside the react-app folder, it is like any other react-project like yours.
Always keep your workflows folder like mine, in the root level of the folder. So create a .github folder, inside of which create another folder as workflows.
Inside workflows folder, create a workflow file with any name using .yml extension. Add the following code to the workflow file.

# This workflow will do a clean installation of node dependencies, cache/restore them, build the source code and run tests across different versions of node

name: Node.js CI for SplitWise React App

on:
    push:
        branches: ["develop"]
    pull_request:
        branches: ["develop"]

jobs:
    build:
        runs-on: ubuntu-latest

        defaults:
            run:
                working-directory: ./react-app/

        strategy:
            matrix:
                node-version: [14.x, 16.x]

        steps:
            - uses: actions/checkout@v3
            - name: Use Node.js ${{ matrix.node-version }}
              uses: actions/setup-node@v3
              with:
                  node-version: ${{ matrix.node-version }}
                  cache: "npm"
                  cache-dependency-path: "./react-app/package-lock.json"

            - run: |
                  npm i
                  npm run build
                  npm run test

What is Yaml file?? 🫠

Yaml (.yml) file syntax is inspired from JSON notation. It's kind of similar to expanded JSON notation without brackets. The space indentation in yaml file serves the purpose of brackets in JSON file.

Let's understand the workflow file line by line. 🤔

All the keys in the workflow file are standard keywords for CI pipeline. They are all self-described, but I will try to help you understand in my way.

name: defines the name of the pipeline
on: defines the rules for git events.
push/pull_request: defines the git events.
branches: defines a value or list of branch names or branch name patterns that uses this workflow.
jobs: defines the jobs for pipeline to run on git events.
build: custom defined name for build job.
runs-on: defines a value or list OS machines that are deployed into server instances.
defaults: takes in nested rules or objects, for overriding default values.
run: defines the run task parameters.
working-directory: under run task, we are mentioning the working directory in our folder structure. In general, it will be the root directory. In my case, I have two variants of the same application, python console app and react web app. I want this workflow to work only for react-app, hence the path ./react-app/.
strategy: defines the rules for the same job with multiple software versions.
matrix: defines the structure to list the software versions over the same job.
node-version: custom key to list node versions, to be used later in common job steps.
steps: defines the start of steps in the later lines of code. Hyphen syntax is used to index each step under a job.
- Each step can be named or ignored.
- Each step can be manually defined like the run step or
- Each step can use existing defined templates defined in the GitHub actions marketplace like in step 2.
- actions/checkout@v3 is necessary to ensure that the jobs are ran on the selected branches.
- actions/setup-node@v3 is used to setup the node in each job with different versions from matrix.
with: defines the rules used for defining multiple jobs over the same steps (like for ensuring software compatibility with multiple dependency software versions).
node-version: a pre-defined keyword for defining the node version needed by actions/setup-node@v3 to setup on the run. We use ${{ variable }} syntax to stuff values into yaml file. Here, I have used it for picking node-versions from matrix and thereby creating multiple jobs.
cache: defines the cache module. Since it is react-app, it uses npm for cache.
cache-dependency-path: it defines the file path for cache and dependency module or package versions. Generally, it is served by package-lock.json or yarn-lock.json file and it will be available in the root directory of the project. In my case, there is slight change in the location package-lock.json file, so I have updated the proper path for it.
run: under steps, it is predefined key that takes a command to execute in the server (ubuntu) against software image defined in the matrix (node) for the specific job.
- You can use pipe (|) operator in the first line, to write multiple series of commands to execute on the same the run.
- If any run command fails, the next series of commands in the order will be prevented from execution.
- And come on! You know the commands necessary for building a react-app. 👍😉

Everything is ready with our CI pipeline, now it's time to check it action. 😎

With all your changes in your local machine, stage them and make a commit.
Push the commit to your remote origin repository.
Head over to GitHub and open your repository. There on the top local nav menu, click on Actions tab.
You should see your workflow file getting used for CI against your commit.

PS: I have been working to fix the errors in my project 🤞. Your project should be doing fine 👍.

Final thoughts 😶‍🌫️

I have shared my knowledge to the best on creating a CI pipeline for building jobs for every code commit with basic and important rules. Please, feel free to share your thoughts and your experiences in the comment section. Happy Coding!! 🤗

How to get started with your first Open Source Contribution??

Satyakoidala — Tue, 04 Apr 2023 08:37:21 +0000

Hey Dev folks, we all knew the urge to kickstart a development project out of someone else idea which we really like and we often coin it as Open Source Contribution. We knew that we want to do it and there are plenty of thoughts wandering in your mind about what to do? and what to use?.

But, most people commonly forget the basic question of how to get started? in the first place. I was in the same dilemma in my initial stages of open source development. So, here I am listing out an easy process to start your first open source contribution.

Following are the steps that I have followed before my first open source contribution,

Step 1:
Learn and practice building any basic skills in the area of your choice of IT career that has potential real life problems. (I chose web development and there is always a scope to learn)

Step 2:
Learn about basic git commands, GitHub repositories and their purpose in Open Source Contributions. (If you know the reason, you will never forget it)

Learn more about git in https://git-scm.com/doc

Step 3:
Next, lookout for GitHub issues in the GitHub community and choose one.

You can search for technology topics or keywords in GitHub search, and in the results you can choose any repository to your likes and checkout the issues section for the repo for any open issues for contribution.

Or if you are in the right season of the year, you might end up in the Hacktoberfest Event (occurs in October, a great place to learn about git and open source contributions).

You can start by just searching using the #hacktoberfest2022 or #hacktoberfest keywords in the GitHub search.

(For more details on hacktoberfest, checkout https://opensource.com/article/22/10/how-to-contribute-hacktoberfest)

Step 4:
After step 3, start interacting with the GitHub repository owner in the issue thread. (Always remember, early bird catches the fly. There might be other developers who are competing for the same issue)

Be the first to interact and ask the owner to assign the issue to you, so that your contribution is reserved for consideration.

Step 5:
After you got yourself an issue to work on, start working on it. Try to satisfy the needs of the issue.

Lastly, try to satisfy yourself with your development, because the passion and efforts you put in reciprocates each other and leaves you a positive mindset.

Once, if you are done with your changes, follow the necessary git steps and make your first PR.

Step 6:
After creating PR, do not forget mention the created PR details in the issue thread as well and update the thread requesting the code owner to review the code.

Wait for the review. If your code manages to pull off the issue, your changes will be accepted and merged.

Voila! and Congratulations!! You have made your first open source contribution.

It is always good to see your changes in live page, you are lucky to get a repo with live deployment after your changes are merged.

My Actions towards my first Open Source Contribution are as below.

Luckily, I had started during the season of Hacktoberfest2022. But, I had covered steps 1 & 2 prior at hand, so all that is left for me is to select an issue and work on it.
So, I have searched for the issues using hacktoberfest2022 keyword and found my first beginner-friendly issue (try to choose the issue of your knowledge or technical expertise). You can refer to my first interactions with GitHub issue owner here, https://github.com/sceary-expert/Codeforces-Problem-of-The-Day/issues/5
I have made the necessary changes and improvements, then created PR. Checkout my first Pull Request, https://github.com/sceary-expert/Codeforces-Problem-of-The-Day/pull/7

Thanks to my efforts, the code owner liked my approach and approved my changes, also deployed it to the live page.

Sometimes, a good approach and passion for development leaves with you more opportunities.

I got more issues from the same code owner and repository. I have made UI improvements as well, along with codeforces API integration for the live page.

Here is the live page URL after my changes got deployed, https://codeforces-probem-of-the-day.netlify.app/

In the end, it all starts with a first step. I hope you will get to know your first steps, if you came till here. Happy Coding! Happy Dev!!

And always do not forget to be grateful to the one who gave you the opportunity. I would like to use this post to thank @sceary-expert for the first opportunity.