---
title: 'Resolve merge conflicts with git rebase'
date: '2023-06-23'
slug: 'resolve-merge-conflicts-with-git-rebase'
thumbnail: '/thumbnails/git.png'
tag: 'git'
canonicalUrl: 'http://localhost:3000/blog'
---

Resolving merge conflicts can sometimes be difficult, and using the GitHub UI may not always be the most effective solution. As the complexity of the conflicts increases, it may be necessary to rely on tools on your local machine rather than the web interface provided by GitHub.

I have discovered that using the `git rebase` command is a useful method for resolving merge conflicts in my feature branch before merging it into the `main` branch. Although it took some time to fully understand the process and the necessary steps.

## Problem

I have been working on a `feature-branch` in an open-source repository for work for quite some time. However, recent commits merged into the main branch have caused conflicts in my branch, preventing me from merging my own commit. I have two options to proceed:

- Resolve the conflicts to merge the branches.
- Create a new pull request if the conflicts are too complex and my changes are of low priority.

## Solution: Resolve conflicts with git rebase

Using `git rebase` in the `feature-branch` allows to bring changes from the `main`, and resolve the merge conflicts. Then, I can use VSCode (which has a Resolve merge conflict editor and is pretty handy) and push the changes back to my feature branch. Once the conflicts are resolved, I can merge my branch into the `main` without any issues which will make GitHub happy.

### Step 1: Fetch the latest changes from the main

Open a fresh terminal tab, and navigate into the repository. On the `main` branch, run:

```shell
git pull
```

This makes sure that the local copy of the `main` branch on my machine has all the latest changes.

### Step 2: Run git log to verify

Running `git log` helps verifying that `main` branch has all the latest commits:

```shell
git log --oneline --graph --decorate --color

# I use an alias: glog
```

### Step 3: Checkout to the feature-branch

Time to switch to the `feature-branch`:

```shell
git checkout feature-branch

# I use an alias: gck feature-branch
```

### Step 4: Run git rebase to bring changes from the main

To bring changes from the `main` to the `feature-branch`, run:

```shell
git rebase main
```

Then run `git status` to know the status of the branch:

```shell
git status

# I use an alias: gs
```

### Step 5: Resolve merge conflicts

If there are merge conflicts, running `git status` will let you know. Open VSCode, click on open Resolve Merge Conflict editor and you can now accept changes in the left tab which shows the latest changes from `main` branch.

On the right side, changes from the current `feature-branch` (probably the ones that are causing conflicts) are shown.

After resolving conflicts, save the file and from the terminal run the following command to stage the modified files:

```shell
git add file-name

# I use an alias: ga file-name

# In case, multiple files modified and need to be staged, run:
git add .
```

Then, run `git status` once again to see if the modified files are staged.

Then run the following command to commit those changes:

```shell
git commit -m "commit message..."

# I use an alias: gc "commit message..."
```

### Step 6: Continue the rebase

Run `git rebase` command with `--continue` flag to continue the rebase process:

```shell
git rebase --continue
```

> **Tip:** If required, save changes by pressing `:wq!` in the terminal.

### Step 7: Verify new commits

Run the following command to verify that the new commits from `feature-branch` are at the top of the commit history and changes from the `main`:

```shell
git log --oneline --graph --decorate --color

# I use an alias: glog
```

### Step 8: Commit changes from local to remote

Finally, push the changes from the local `feature-branch` to the remote `feature-branch`:

```shell
git push --force
```

## Summary

A few added rules I think are worth mentioning in this process:

- Only use rebase for local branches and if you are the owner of that branch.
- If you anticipate that the conflicts can become messy, use the strategy described above at regular intervals to avoid a lot of conflicts.

> A big thank you to my colleague [Sundeep Peswani](https://www.sundeeppeswani.com/) for teaching this via live coding and jumping on a call to help me understand the process and making my life easier.


Resolve merge conflicts with git rebase

---
title: 'How to push local git tag to remote repository on GitHub'
date: '2022-06-26'
slug: 'push-local-git-tag-to-remote-repository-on-github'
thumbnail: '/thumbnails/git.png'
tag: 'git'
canonicalUrl: 'https://amanhimself.dev/blog/push-local-git-tag-to-remote-repository-on-github/'
---

After creating a git tag locally on a local project, I needed to push it on GitHub. The reason is that I'm hosting the project repository on GitHub.

## Pushing a tag to GitHub

Pushing a tag in git is similar to pushing a branch. The only difference is that it needs the specific git tag name.

```shell
git push -u origin <tag_name>
```

Here is an example. I had already created a new tag, `v0.1` on my local project. To push it to GitHub, I had to run:

```shell
gpush v0.1
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/amandeepmittal/[project-name].git
 * [new tag]         v0.1 -> v0.1
```

Note: I use the `gpush` alias for `git push -u origin`. Complete list of all the aliases I use for git, check this [dotfile](https://github.com/amandeepmittal/dotfiles/blob/master/.zshrc).

## Checking for if a tag is already pushed

To check if a tag is only available on local, run:

```shell
git push --tags --dry-run
```

The `--dry-run` option in the above command summarizes what will be included in the next commit.

If the output of the above command states `Everything up-to-date`, it means there are no tags available to push.

In case when the above command comes back with an output like the below, it means that the tag is available to push.

```shell
To https://github.com/amandeepmittal/[project-name].git
 * [new tag]         v0.1 -> v0.1
```


How to push local git tag to remote repository on GitHub

---
title: 'How to rename default branch in Git and GitHub'
date: '2022-01-10'
thumbnail: '/thumbnails/git.png'
slug: 'how-to-rename-default-branch-name-in-git-and-github'
tag: 'git'
canonicalUrl: 'https://amanhimself.dev/blog/how-to-rename-default-branch-name-in-git-and-github/'
---

I'm currently [maintaining a GitHub repo](https://github.com/amandeepmittal/react-native-examples) that has grown over the last year. It primarily contains all the example code that I create when working on React Native and Expo articles and tutorials.

Recently, I switched the default branch to `main`. Here are the steps I took. All of these commands execute inside a terminal window.

Start by moving the default branch locally using the `-m` flag.

```shell
git branch -m master main
```

Above, `master` is the old branch name and `main` is the new branch name.

Set the new branch as the local default on the remote. By default, Git doesn't allow renaming a remote branch.

```shell
git push -u origin main

# output
* [new branch]      main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.
```

Set the current local HEAD branch to point to the new branch on GitHub.

```shell
git remote set-head origin main
```

Now, go to the GitHub repo. Open Settings > Branches. Under Default Branch, click the edit button to switch to the `main` branch.

![ss1](https://i.imgur.com/T9Mm8g5.png)

Now, go back to the terminal window and run the following command to delete the previous default branch name.

```shell
git push origin --delete master

# output
To https://github.com/account/repo.git
- [deleted]         master
```

That's it!


🔥 3 Posts filtered by tag "git"

Resolve merge conflicts with git rebase

How to push local git tag to remote repository on GitHub

How to rename default branch in Git and GitHub