Git

A commit is like a snapshot of the Git repository at one point in time. Adding commits keep track of our progress and changes as we work. Git considers each commit change point or "save point". It is a point in the project you can go back.

You should make new commits often, based around logical units of change.

When we commit, we should always include a message.

By adding clear messages to each commit, it is easy for yourself (and others) to see what has changed and when.

The main workflow for a developer will follow these steps

1. Create a branch for the changes to be made and give it a name according to the naming convention.
2. Commit changes to the branch. There are often multiple commits for a bug fix or feature.
3. Push the branch to the remote repository.
4. Create a pull request so other team members can review the changes. To incorporate feedback, more commits might be needed and changes to be pushed.
5. Complete the pull request and resolve any merge conflicts from changes other team members made after creating the branch.

This short Snipp shows you how to remove the last commit from the git repository.

1. Check the logs

First of all, check your local commit with messages before removing the last commit. Run the following command to check the logs in one line.

git log --oneline

2. Remove the last commit from the local branch

Now, Run the following command to remove the last commit and discard the changes from the local branch.

git reset --hard HEAD~1

Checkout the different ways to Undo commit before push in Git.

3. Update remote repository

At last, we will update the files and again need to push with force. It will delete the previous commit and keep a new one on the remote git repository.

git push origin <name_of_branch> -f

Now you can check the logs to verify the commit in the git repository.

This set gives an overview of the following concepts in GitHub.

• Repository
• Issues
• Pull Request
• Label
• Template
• Project
• Milestone
• Action

Starting a new repository should be simple—but sometimes GitLab surprises you with errors when pushing your first branch. One common issue happens when trying to create a protected branch (like dev) directly from a local repository. The result? A rejected push and a confusing message.

Here’s the key idea:
GitLab does not allow protected branches to be created “from nothing.”
They must be based on a branch or commit that already exists on the server.

Many developers used to start like this:

git checkout -b dev
git commit -m "Initial commit" --allow-empty
git push -u origin dev

This worked before, but now GitLab blocks it if dev is protected. The problem is not the empty commit—it’s that the branch has no existing base on the remote.

The correct approach is to create a base branch first:

git checkout -b main
git commit -m "Initial commit" --allow-empty
git push -u origin main

git checkout -b dev
git push -u origin dev

Now dev is created from an existing branch (main), and GitLab accepts it.

Alternative solutions:

• Temporarily remove protection on dev
• Create the first branch using the GitLab UI

Takeaway:
Always create at least one branch on the remote before pushing protected branches. This small change avoids errors and keeps your workflow smooth.