DEV Community: Cristian Jonhson Alvarez

How to Change a Public Repository to Private Using GitHub CLI

Cristian Jonhson Alvarez — Tue, 30 Jun 2026 21:13:07 +0000

When working on personal, academic, or professional projects, we often start a repository as public to share progress, test configurations, or collaborate openly. However, at some point, it may become necessary to protect the code, especially if the project contains business logic, internal configurations, technical documentation, or an architecture that we do not want to expose yet.

In this article, we will see how to change a repository from public to private using GitHub CLI (gh), directly from the terminal.

Prerequisite

Before running the commands, you need to have GitHub CLI installed and configured.

You can check if gh is installed with:

gh --version

You can also verify if you are properly authenticated:

gh auth status

If you are not logged in, you can authenticate with:

gh auth login

Important Security Note

Changing a repository from public to private does not remove any sensitive data that may have already been exposed. If you accidentally published secrets, API keys, tokens, or credentials, rotate them immediately.

Change a Public Repository to Private

The most direct way to change the visibility of a repository using GitHub CLI is:

gh repo edit OWNER/REPO \
  --visibility private \
  --accept-visibility-change-consequences

For example:

gh repo edit username/my-repository \
  --visibility private \
  --accept-visibility-change-consequences

The important flag here is:

--accept-visibility-change-consequences

GitHub requires this flag because changing the visibility of a repository can have consequences, such as affecting forks, stars, watchers, access permissions, or related integrations.

Change Visibility from the Local Repository Folder

If you are already inside the project folder and the local repository has its GitHub remote configured, you can run:

gh repo edit --visibility private \
--accept-visibility-change-consequences

Example:

cd my-repository
gh repo edit --visibility private \
--accept-visibility-change-consequences

If everything goes well, GitHub CLI will show a message like this:

✓ Edited repository username/my-repository

This means the repository was updated successfully.

Verify That the Repository Is Private

After changing the visibility, it is a good practice to verify the repository status.

To check a specific repository:

gh repo view username/my-repository --json visibility

The expected response should be:

{
  "visibility": "PRIVATE"
}

You can also verify it from inside the local project folder:

gh repo view --json visibility

Expected result:

{
  "visibility": "PRIVATE"
}

This confirms that the repository is no longer public.

Open the Repository in the Browser

You can also open the repository directly from the terminal using:

gh repo view username/my-repository --web

Or, if you are inside the local project folder:

gh repo view --web

This will open the repository on GitHub in your browser, where you can visually review the configuration.

What Happens to Collaborators?

When a repository becomes private, only the following users will have access:

The repository owner
Manually added collaborators
Organization members with the corresponding permissions, if applicable

You can review the collaborators with:

gh api repos/username/my-repository/collaborators

Useful Command Summary

Change a repository to private:

gh repo edit OWNER/REPO \
--visibility private \
--accept-visibility-change-consequences

Change a repository to private from the local folder:

gh repo edit --visibility private \
--accept-visibility-change-consequences

Verify repository visibility:

gh repo view OWNER/REPO --json visibility

Open the repository on GitHub:

gh repo view OWNER/REPO --web

Conclusion

GitHub CLI makes repository management faster and more efficient directly from the terminal. Changing a repository from public to private is a simple task, but it is an important step when you need to protect source code, internal documentation, configuration files, or an unfinished project.

This workflow is especially useful for projects that are still under development, contain sensitive information, or are not ready to be publicly shared.

With a single command, you can update the repository visibility and verify the result without leaving the terminal.

Fixing “release version 17 not supported” on macOS for Spring Boot 3

Cristian Jonhson Alvarez — Tue, 23 Jun 2026 00:54:51 +0000

If you are trying to run a Spring Boot 3 project and Maven throws release version 17 not supported, the problem is usually not your code. Most of the time, Maven is using an older JDK.

When working with modern Spring Boot 3 projects, one of the main requirements is using Java 17 or higher. This may sound simple, but in practice, it is common to run into errors when Maven is still using an older Java version, such as Java 8 or Java 11.

In this article, we will review a common case: trying to run a Java Spring Boot API and getting the following error:

Fatal error compiling: error: release version 17 not supported

Project context

Let’s assume we are working on a REST API built with:

Java 17
Spring Boot 3
Maven
PostgreSQL
Docker
macOS Intel

The application can be any typical backend project: a products API, users API, sales system, inventory system, ticketing system, reports API, or an integration service with a database.

The important point is that the project is configured to compile with Java 17.

The problem

When running the project with Maven:

mvn clean spring-boot:run

the following error appears:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.13.0:compile
Fatal error compiling: error: release version 17 not supported

At first, it may look like the problem is in the code or in the pom.xml. However, in many cases, the real issue is the Java version that Maven is actually using.

Checking the pom.xml file

In a Spring Boot 3 project, you will usually find a configuration like this:

<properties>
    <java.version>17</java.version>
</properties>

This means the project needs to be compiled using Java 17.

You may also see a Spring Boot 3 parent like this:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.3.5</version>
    <relativePath/>
</parent>

Spring Boot 3 requires Java 17 or higher. So, if Maven is running with Java 11 or Java 8, the compilation will fail.

Checking the current Java version

First, check the Java version:

java -version

A problematic output could look like this:

openjdk version "11.0.25" 2024-10-15
OpenJDK Runtime Environment Homebrew
OpenJDK 64-Bit Server VM Homebrew

In this case, the terminal is using Java 11.

Then check Maven:

mvn -version

If Maven is also using Java 11, you may see something like this:

Apache Maven 3.9.8
Java version: 11.0.25

This explains the error: the project requires Java 17, but Maven is compiling with Java 11.

Checking installed JDKs on macOS

On macOS, you can list the installed Java versions with:

/usr/libexec/java_home -V

Example output:

Matching Java Virtual Machines (2):
    11.0.25 (x86_64) "Homebrew" - "OpenJDK 11.0.25"
    1.8.371.11 (x86_64) "Oracle Corporation" - "Java"

In this case, the system only has Java 11 and Java 8 installed. Therefore, Java 17 must be installed.

Installing Java 17 with Homebrew

On macOS Intel, you can install Java 17 with Homebrew:

brew install openjdk@17

On some machines, especially with older macOS or Xcode versions, Homebrew may compile several dependencies from source. This can take a long time.

To check how long the installation has been running, you can use:

ps -axo pid,etime,command | grep -E "brew|make|python|openjdk" | grep -v grep

Example output:

33961    01:14:20 /usr/local/Homebrew/Library/Homebrew/brew.rb install openjdk@17

This means the installation has been running for approximately 1 hour, 14 minutes, and 20 seconds.

Configuring Java 17 temporarily

Once the installation finishes, configure the current terminal session to use Java 17:

export JAVA_HOME=/usr/local/opt/openjdk@17/libexec/openjdk.jdk/Contents/Home
export PATH=$JAVA_HOME/bin:$PATH
hash -r

Then verify the Java version:

java -version

You should see something similar to:

openjdk version "17..."

Also check Maven:

mvn -version

Maven should now show Java 17:

Java version: 17...

Making Java 17 permanent

To avoid repeating this configuration every time you open a new terminal, add the environment variables to your ~/.zshrc file:

echo 'export JAVA_HOME=/usr/local/opt/openjdk@17/libexec/openjdk.jdk/Contents/Home' >> ~/.zshrc
echo 'export PATH=$JAVA_HOME/bin:$PATH' >> ~/.zshrc
source ~/.zshrc

Then check again:

java -version
mvn -version

Running the API again

With Java 17 configured, go to your project directory:

cd /path/to/your/project

Run the project again:

mvn clean spring-boot:run

If everything is correct, Spring Boot should start the API on the configured port, usually:

http://localhost:8080

Testing endpoints

Some common test endpoints may be:

curl http://localhost:8080/actuator/health

Or, if your project has a custom health endpoint:

curl http://localhost:8080/api/health

If your project includes Swagger or OpenAPI, you can check the documentation at:

http://localhost:8080/swagger-ui.html

Alternative: use Docker if you do not want to install Java 17 locally

If installing Java 17 with Homebrew takes too long or fails because of dependencies, a practical alternative is running the API with Docker using an image that already includes Java 17.

For example, a simple Dockerfile could look like this:

FROM eclipse-temurin:17-jdk

WORKDIR /app

COPY . .

RUN ./mvnw clean package -DskipTests

EXPOSE 8080

CMD ["java", "-jar", "target/app.jar"]

Another option is compiling the project locally and then copying the .jar file into the container:

FROM eclipse-temurin:17-jre

WORKDIR /app

COPY target/*.jar app.jar

EXPOSE 8080

CMD ["java", "-jar", "app.jar"]

This approach avoids depending on the locally installed JDK and makes the project more portable.

Common errors

Error: release version 17 not supported

Cause: Maven is using Java 8, Java 11, or any version lower than Java 17.

Solution:

java -version
mvn -version
export JAVA_HOME=/usr/local/opt/openjdk@17/libexec/openjdk.jdk/Contents/Home
export PATH=$JAVA_HOME/bin:$PATH

Maven still uses Java 11

Run:

hash -r
mvn -version

If Maven still shows Java 11, check your ~/.zshrc, ~/.bash_profile, or any other environment configuration file.

Homebrew takes too long to install Java 17

On older macOS versions, Homebrew may compile dependencies from source. You can monitor the process with:

ps -axo pid,etime,command | grep -E "brew|make|python|openjdk" | grep -v grep

Java 17 is installed, but Maven uses Java 11

This usually happens when JAVA_HOME points to another version.

Solution:

export JAVA_HOME=/usr/local/opt/openjdk@17/libexec/openjdk.jdk/Contents/Home
export PATH=$JAVA_HOME/bin:$PATH
mvn -version

Conclusion

The error:

release version 17 not supported

does not necessarily mean your Spring Boot project is incorrectly configured. In many cases, it simply means Maven is using a Java version lower than the one required by the project.

For Spring Boot 3 projects, it is recommended to use Java 17 or higher. On macOS, you can install it with Homebrew, configure JAVA_HOME, and verify that Maven is using the correct version.

Before changing your code or modifying the pom.xml, always check:

java -version
mvn -version

Many times, the solution is in the development environment, not in the application itself.

Hope this helps you avoid wasting time debugging your Spring Boot project when the real issue is just the local Java version.

Java 8 vs Java 11 vs Java 17: Which to use and why it matters in real-world projects

Cristian Jonhson Alvarez — Fri, 19 Jun 2026 02:05:33 +0000

Java is one of the most widely used languages in the enterprise world. Many backend applications, banking systems, REST APIs, microservices, and enterprise platforms still run on versions like Java 8, Java 11, or Java 17.

But when working on real-world projects, a very common question arises:

What really changes between Java 8, Java 11, and Java 17?

In this article, we will look at the main differences between these versions, why they remain important, and which one is best to use in modern projects.

1. Why Compare Java 8, 11, and 17?

Java 8, Java 11, and Java 17 marked important milestones in the evolution of the language.

Java 8 modernized the way code is written with lambdas, streams, and functional programming.
Java 11 consolidated a more modular and modern stage of the JDK.
Java 17 became a widely used foundation for current projects with Spring Boot 3, modern Jakarta EE, and cloud-native applications.

In many companies, we still find legacy applications in Java 8, intermediate projects in Java 11, and recent developments in Java 17.

2. Quick Summary

Version	Release Year	Main Focus	Common Use
Java 8	2014	Lambdas, Streams, new Date API	Legacy systems and older enterprise applications
Java 11	2018	JDK cleanup, HTTP Client, performance improvements	Migration from Java 8 and modern backend services
Java 17	2021	Records, Sealed Classes, modern language features	Modern projects, Spring Boot 3 and cloud architecture

3. Java 8: The Great Modern Leap

Java 8 was one of the most important versions of the language. Before Java 8, writing code to iterate through lists, filter data, or pass behavior as a parameter was much more verbose.

Java 8 introduced features that changed the way we write code.

Main Features of Java 8

Lambda expressions.
Stream API.
Functional interfaces.
Method references.
Optional.
New date API with java.time.
Default methods in interfaces.

Example before Java 8

List<String> names = Arrays.asList("Ana", "Luis", "Carlos");

for (String name : names) {
    if (name.startsWith("A")) {
        System.out.println(name);
    }
}

Example with Java 8

List<String> names = Arrays.asList("Ana", "Luis", "Carlos");

names.stream()
     .filter(name -> name.startsWith("A"))
     .forEach(System.out::println);

The code with Java 8 is more declarative. Instead of saying exactly how to traverse the list, we express what we want to obtain.

4. Stream API in Java 8

The Stream API allows you to work with collections in a more expressive way.

Example:

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);

List<Integer> evenNumbers = numbers.stream()
        .filter(n -> n % 2 == 0)
        .collect(Collectors.toList());

System.out.println(evenNumbers);

Result:

[2, 4, 6]

This is very useful for transforming, filtering, sorting, or grouping data.

5. New Date API in Java 8

Before Java 8, working with dates using Date or Calendar was cumbersome.

Java 8 introduced java.time, a much clearer API.

LocalDate currentDate = LocalDate.now();
LocalDate deliveryDate = currentDate.plusDays(7);

System.out.println(deliveryDate);

You can also work with date and time:

LocalDateTime now = LocalDateTime.now();

System.out.println(now);

java.time is more readable, safer, and better suited for modern applications.

6. Java 11: A Cleaner Version Ready for Services

Java 11 arrived after the change in the Java release cycle. It is a widely used version in companies because it allowed migration from Java 8 to a more modern base without making too big a leap.

Main Features of Java 11

New standard HTTP Client.
Use of var in lambda parameters.
New methods in String.
New methods for files.
Execution of .java files without prior manual compilation.
Removal of some legacy modules from the JDK.
Performance and security improvements.

7. HTTP Client in Java 11

Previously, many projects used external libraries such as Apache HttpClient, OkHttp, or RestTemplate to make HTTP requests.

Java 11 incorporated a standard HTTP client in the java.net.http package.

Example:

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

public class HttpClientExample {

    public static void main(String[] args) throws Exception {
        HttpClient client = HttpClient.newHttpClient();

        HttpRequest request = HttpRequest.newBuilder()
                .uri(URI.create("https://api.github.com"))
                .GET()
                .build();

        HttpResponse<String> response = client.send(
                request,
                HttpResponse.BodyHandlers.ofString()
        );

        System.out.println(response.statusCode());
        System.out.println(response.body());
    }
}

This makes it possible to consume REST APIs using only the JDK, without adding an external HTTP client library.

How to Create a Pull Request from the Terminal Using GitHub CLI

Cristian Jonhson Alvarez — Wed, 17 Jun 2026 15:37:35 +0000

If you work with Git every day, switching back and forth between your terminal and GitHub's web interface can interrupt your workflow.

Fortunately, GitHub CLI (gh) allows you to create, review, and manage Pull Requests directly from the terminal. In this guide, you'll learn how to create a Pull Request from a feature branch to main without ever leaving your command line.

Prerequisites

Before getting started, make sure you have:

Git installed
GitHub CLI installed
A GitHub account
Authenticated GitHub CLI

Authenticate with GitHub:

gh auth login

Verify your authentication:

gh auth status

1. Create a Feature Branch

Start by updating your local main branch:

git checkout main
git pull origin main

Create a new feature branch:

git checkout -b feature/add-user-service

Or using the newer Git syntax:

git switch -c feature/add-user-service

2. Make Your Changes

After implementing your changes, check your working tree:

git status

Stage and commit your changes:

git add .
git commit -m "Add user service implementation"

3. Push the Branch to GitHub

Push the branch to the remote repository:

git push -u origin feature/add-user-service

The -u flag establishes tracking between your local and remote branch.

4. Create the Pull Request

Option 1: Explicit Branch Names

Create a Pull Request specifying both source and target branches:

gh pr create \
  --base main \
  --head feature/add-user-service \
  --title "Add user service implementation" \
  --body "This PR adds the user service and related business logic."

Option 2: Automatically Detect the Current Branch

A cleaner approach is to let Git determine the current branch:

gh pr create \
  --base main \
  --head $(git branch --show-current) \
  --title "Add user service implementation" \
  --body "This PR adds the user service and related business logic."

This is especially useful when working with multiple feature branches.

Option 3: Interactive Mode

GitHub CLI can guide you through the process:

gh pr create

You will be prompted to:

Select the base branch
Select the head branch
Enter a title
Enter a description

Option 4: Open GitHub's PR Form in Your Browser

If you prefer GitHub's web interface while keeping the CLI workflow:

gh pr create --web

This command opens the Pull Request page in your browser with most fields already prefilled.

5. View the Pull Request

List all Pull Requests:

gh pr list

View details of the current Pull Request:

gh pr view

Open the Pull Request in your browser:

gh pr view --web

Optional: Merge the Pull Request

Once your Pull Request has been approved, you can merge it directly from the terminal.

Standard merge:

gh pr merge

Squash merge and delete the feature branch:

gh pr merge --squash --delete-branch

Regular merge and delete the feature branch:

gh pr merge --merge --delete-branch

Complete Example

git checkout main
git pull origin main

git checkout -b feature/add-user-service

git add .
git commit -m "Add user service implementation"

git push -u origin feature/add-user-service

gh pr create \
  --base main \
  --head $(git branch --show-current) \
  --title "Add user service implementation" \
  --body "This PR adds the user service and related business logic."

gh pr view --web

Why Use GitHub CLI for Pull Requests?

Using GitHub CLI offers several advantages:

Faster workflow
Less context switching
Easy automation in scripts
Better productivity for terminal-first developers
Seamless integration with Git and GitHub

For developers who spend most of their day in the terminal, GitHub CLI is one of the simplest ways to streamline the Pull Request process.

Conclusion

GitHub CLI makes Pull Request creation simple, fast, and efficient. Whether you prefer a fully terminal-based workflow or a hybrid approach with the browser, gh pr create provides multiple ways to open Pull Requests with minimal effort.

Once you get used to it, you'll rarely need to manually navigate GitHub's interface just to create a Pull Request.

Most beginners misuse these Git branch commands: main, checkout -b, switch -c, and push -u explained

Cristian Jonhson Alvarez — Fri, 12 Jun 2026 19:27:31 +0000

Why these Git commands confuse so many beginners

A lot of developers use these commands from memory:

git branch -M main
git checkout -b feature/inicial
git switch -c feature/inicial
git push -u origin feature/inicial

The problem?

Most people can type them.
Few people can clearly explain why they use them.

And that matters.

Because if you do not understand what these commands actually do, you will eventually mess up your branch flow, push to the wrong place, or confuse yourself when working across multiple repos.

Let’s fix that.

The real meaning of `git branch -M main`

This command:

git branch -M main

renames your current branch to main.

The important part is -M.

It is basically the forced version of branch rename:

-m → rename branch
-M → rename branch and force it if needed

So when you run:

git branch -M main

You are not “creating GitHub main magic.”
You are simply saying:

Rename whatever branch I am currently on to main.

What about `master`?

This command works the same way:

git branch -M master

The only difference is the target name.

Historically, many repositories used master.
Today, most modern repositories default to main.

Better option for brand new repos

If the repository is brand new, this is cleaner:

git init -b main

That way, you start with main immediately and avoid renaming later.

`git checkout -b` vs `git switch -c`: same result, different philosophy

These two commands are often used for the exact same outcome.

Classic Git style

git checkout -b feature/inicial

Modern Git style

git switch -c feature/inicial

Both commands:

create a new branch
move you to that branch immediately

So why do we have both?

Because `checkout` does too much

git checkout is one of those old Git commands that can do many unrelated things:

switch branches
restore files
move around history

That flexibility is powerful, but also confusing.

git switch was introduced to make the intent much clearer.

When you write:

git switch -c feature/inicial

it is obvious that you are doing branch work.

That is why many teams now prefer switch for teaching and day-to-day use.

Which one should you use?

If you are working on a modern Git version, prefer:

git switch -c feature/inicial

It is clearer, easier to teach, and easier to read.

Why `git push -u origin feature/inicial` is more important than people think

Creating a local branch is only half the job.

Until you push it, GitHub does not know it exists.

That is where this command comes in:

git push -u origin feature/inicial

It does two things at once:

1) Pushes the branch to the remote

It sends your local feature/inicial branch to the remote called origin.

2) Sets upstream tracking

This is the part beginners usually skip over.

The -u means Git remembers the relationship between:

your local branch
the remote branch it tracks

So after this first push, you can usually just run:

git push

and later:

git pull

without typing the full branch name again.

That is why -u is such a useful habit.

The workflow most beginners actually need

If you want a simple, clean branch workflow, use this:

git init -b main
git add .
git commit -m "Initial commit"
git switch -c feature/inicial
git push -u origin feature/inicial

If you already initialized the repository and need to rename the current branch first:

git init
git branch -M main
git add .
git commit -m "Initial commit"
git switch -c feature/inicial
git push -u origin feature/inicial

That is enough for a huge number of personal projects and team workflows.

Can you do this with `gh`?

Partly, yes.

GitHub CLI is excellent for GitHub-related actions, but it does not replace core Git branch commands in the normal day-to-day flow.

What `gh` does well

It is great for creating the remote repository from the terminal:

gh repo create my-project --public --source=. --remote=origin --push

That command can:

create the GitHub repo
connect it as origin
push your local code

What you should still do with Git

For regular local branch creation, Git is still the standard:

git switch -c feature/inicial
git push -u origin feature/inicial

Where `gh` becomes really useful again

Once the branch exists, gh is excellent for pull requests:

gh pr create --base main --head feature/inicial --title "Create initial feature branch" --body "This PR introduces the initial feature branch."

And if your team uses GitHub issues, there is a very useful workflow around issue-based branch creation.

The mistake many people make

They memorize the command.
They never learn the intent.

So they end up asking things like:

“Why didn’t my branch appear on GitHub?”
“Why does git push say there is no upstream branch?”
“Why do I have master locally and main remotely?”

The answer is almost always the same:

They followed commands mechanically instead of understanding the branch lifecycle.

That lifecycle is simple:

create repo → define main branch → create feature branch → push and track upstream → open PR

Once you see that flow, the commands stop feeling random.

Final takeaway

If you only keep one mental model from this article, keep this one:

git branch -M main → rename current branch to main
git checkout -b name → create branch and switch to it
git switch -c name → same goal, cleaner modern syntax
git push -u origin name → publish the branch and set upstream tracking
gh → great for repo creation and PR workflows, not a full replacement for Git branch work

Git is easier when you stop memorizing commands and start understanding the sequence.

That is when branching becomes predictable instead of stressful.

Quick command summary

git init -b main
git switch -c feature/inicial
git push -u origin feature/inicial

If the repo already exists and you need to rename the current branch:

git branch -M main

If you want to create the GitHub repository from the terminal:

gh repo create my-project --public --source=. --remote=origin --push

What do you prefer in your daily workflow: `git checkout -b` or `git switch -c`?

If you are teaching Git to juniors, standardizing team workflows, or just trying to stop fighting branch confusion every week, start by simplifying the mental model—not just the commands.

Reset, revert, and reflog: the ultimate guide to undoing commits without losing your repo

Cristian Jonhson Alvarez — Wed, 10 Jun 2026 20:56:25 +0000

😰 Story time: I ran git reset --hard HEAD~1, force pushed… and then realized I needed that file back.

TL;DR

Not pushed yet → reset
Pushed + shared branch → revert
“Lost” a commit → git reflog

The real-world scenario

You’re working on a repo and you create commits like:

chore: remove compiled artifacts from the repository
chore: add .gitignore to exclude unnecessary files

Then you try to undo the last commit, you run push --force-with-lease, and later you say:

“I need to recover that file.”

Let’s go step by step.

1) Undo the last commits: reset vs revert

Rule of thumb:

✅ Working alone / not pushed yet → use reset
👥 Shared branch / already pushed → use revert

Before you copy/paste commands, get your current branch name:

git branch --show-current

Use that value wherever you see YOUR_BRANCH.

Option A: `reset` (rewrites history)

Useful when you want those commits to disappear from the history.

Deletes commits and discards changes (hard mode):

git reset --hard HEAD~2

Deletes commits but keeps changes staged (soft mode):

git reset --soft HEAD~2

GitHub note (force push): If you already pushed, to make the remote match you must force push.

Avoid --force and use:

git push --force-with-lease origin YOUR_BRANCH

✅ --force-with-lease is safer because it won’t overwrite remote work you don’t have locally.

⚠️ If the branch is protected (common on main/master), GitHub may block force pushes.

Example:

git push --force-with-lease origin master

Option B: `revert` (does NOT rewrite history)

Recommended when:

Other people are working on the repo
The branch is shared
The branch is protected (e.g., main/master)

It creates new commits that undo the changes:

git revert --no-edit HEAD~2..HEAD
git push origin YOUR_BRANCH

2) Recover commits after `reset --hard` with `reflog`

If you ran:

git reset --hard HEAD~1

and then regretted it, your lifeline is:

git reflog

Real example output:

dc65430 HEAD@{0}: reset: moving to HEAD~1
3bfb189 HEAD@{1}: commit: chore: add .gitignore to exclude unnecessary files
dc65430 HEAD@{2}: commit: chore: remove compiled artifacts from the repository

You can see the “lost” commit still exists: 3bfb189.

To return to that state:

git reset --hard 3bfb189

If you also want GitHub to match:

git push --force-with-lease origin YOUR_BRANCH

3) Restore a specific file from an earlier commit

Sometimes you don’t want to move the whole branch—only recover one file that existed in a past commit.

Important

This command always requires a path:

git restore --source <COMMIT> -- <FILE_PATH>

Common example: restore .gitignore from 3bfb189:

git restore --source 3bfb189 -- .gitignore

Then save it in history:

git add .gitignore
git commit -m "chore: restore .gitignore"
git push origin YOUR_BRANCH

Don’t know the exact file path?
List the files touched by that commit:

git show --name-status --pretty="" 3bfb189

Or list everything that exists in that commit:

git ls-tree -r 3bfb189 --name-only

Once you find the exact path, restore it:

git restore --source 3bfb189 -- real/path/to/file.ext

Restore EVERYTHING from a commit (warning: overwrites)

⚠️ This can overwrite local changes in your working tree:

git restore --source 3bfb189 -- .

4) Change the last commit message

If you have NOT pushed yet

git commit --amend -m "new message"

If you ALREADY pushed to GitHub

git commit --amend -m "new message"
git push --force-with-lease origin YOUR_BRANCH

5) Tips to avoid Git pain (seriously)

Before doing an aggressive reset, create a “backup branch”:

git branch backup-before-reset

Prefer --force-with-lease over --force
If you’re working with a team, prefer revert over reset
reflog is your “secret history”: when something “disappears”, check git reflog

Wrap-up

If you ever feel like you “lost” commits or files, remember:

git reflog finds the commit you can’t see anymore
git restore --source restores specific files without breaking everything
reset rewrites history (requires force push)
revert is team-friendly

Your turn 👻

What’s your worst Git mistake? Did you manage to recover it, or did you have to start over? Drop your story in the comments.

How to Create a GitHub Repository from the Terminal Using GitHub CLI

Cristian Jonhson Alvarez — Wed, 10 Jun 2026 20:44:15 +0000

When working on a local project, we usually create the repository on GitHub first, copy the remote URL, and then connect it to our local project.

But there is a cleaner way to do it directly from the terminal using GitHub CLI.

1. Initialize Git in Your Project

Go to your project folder:

cd your-project-name

Initialize Git:

git init

2. Authenticate with GitHub CLI

If you have not logged in yet, run:

gh auth login

During the process, you can choose:

GitHub.com
SSH
Login with a web browser

3. Create the Remote Repository from Local

To create the repository on GitHub and add it as origin, run:

gh repo create repository-name --public --source=. --remote=origin

Example:

gh repo create IA_ML_DL_python_fundamentos --public --source=. --remote=origin

For a private repository:

gh repo create repository-name --private --source=. --remote=origin

4. Verify the Remote

Check that origin was added correctly:

git remote -v

You should see something like:

origin  git@github.com:username/repository-name.git (fetch)
origin  git@github.com:username/repository-name.git (push)

5. Create the First Commit

Add your files:

git add .

Create the first commit:

git commit -m "Initial commit"

6. Push the Project to GitHub

Make sure your main branch is named main:

git branch -M main

Push your project:

git push -u origin main

Full Command Summary

git init
gh auth login
gh repo create repository-name --public --source=. --remote=origin
git add .
git commit -m "Initial commit"
git branch -M main
git push -u origin main

Conclusion

Using gh repo create allows you to create a GitHub repository directly from the terminal, connect it as origin, and push your local project without manually creating the repository from the browser.

It is a faster, cleaner, and more professional workflow for starting new projects on GitHub.

Getting Started with AWS: A Practical Guide for Beginners

Cristian Jonhson Alvarez — Mon, 06 Jan 2025 18:28:52 +0000

By the end, you’ll know exactly what to learn first on AWS—and you’ll have 2 mini-projects to prove it.

✅ Plus: you’ll set up Budgets on day one to avoid surprise costs.

TL;DR

Start with EC2, S3, IAM, RDS
Build 1–2 tiny projects (static website + simple API)
Keep costs under control from day one (Budgets + Free Tier)
✅ “Set up AWS Budgets on day 1 to avoid surprise bills.”

1. What is AWS, and why should you learn it?
2. Create your AWS account (and avoid surprise costs)
3. Get familiar with the AWS Console
4. Learn the core services (first 4)
5. Build your first projects
6. Training and certifications
7. Join the community
8. Final tips
Conclusion

1. What is AWS, and why should you learn it?

AWS is a set of cloud services that lets you build and run applications without managing physical servers.

Why learn AWS?

Job opportunities: AWS skills are in high demand across dev, DevOps, data, and security.
Versatility: You can build websites, APIs, databases, analytics, CI/CD, and more.
Pay-as-you-go: You can start small and only pay for what you use.

2. Create your AWS account (and avoid surprise costs)

To start, you need an AWS account:

Go to https://aws.amazon.com/
Click Create a Free Account
Register with email + credit card (AWS uses it for verification and billing)

✅ Cost safety tip (do this immediately):

Set up AWS Budgets and billing alerts the same day you create the account.

Example:

“Go to Billing → Budgets → Create budget (monthly)”.

Free Tier basics

AWS offers a Free Tier for many services (some are 12 months, some always-free, some trials).
Always check pricing pages before creating resources.

3. Get familiar with the AWS Console

The AWS Management Console is where you’ll create and manage services.

Spend time on:

Navigating services (search bar is your best friend)
Switching regions (top-right)
Understanding IAM users/roles (more below)

Pro tip: Learn the AWS CLI once you’re comfortable in the console:

aws --version
aws sts get-caller-identity

4. Learn the core services (first 4)

If you only learn these 4 first, you’ll already understand most AWS basics.

4.1 EC2 (Elastic Compute Cloud)

Virtual servers in the cloud.

Practice:

Launch an instance (Amazon Linux / Ubuntu)
Connect via SSH
Stop/terminate it to avoid costs

⚠️ Reminder: Stop/terminate your instance when done.

4.2 S3 (Simple Storage Service)

Object storage for files (images, backups, static websites).

Practice:

Create a bucket
Upload/download files
Learn permissions (private vs public)

4.3 RDS (Relational Database Service)

Managed databases (PostgreSQL, MySQL, etc).

Practice:

Create a small PostgreSQL instance (Free Tier eligible if available)
Connect from local app
Learn basics: security groups + subnet groups

4.4 IAM (Identity and Access Management)

Users, roles, permissions.

Practice:

Create an IAM user with least privilege
Create an IAM role (used by EC2/Lambda)
Learn policies (managed vs inline)

🔥 If you learn IAM early, you’ll avoid most “why is access denied?” pain later.

5. Build your first projects

The fastest way to learn AWS is to build.

Project 1: Static website with S3 + CloudFront

Goal: host a simple website (HTML/CSS/JS) in S3 and deliver it via CDN.

Steps:

Upload site files to S3
Configure static hosting (or private bucket + CloudFront)
(Optional) Add a custom domain with Route 53

Project 2: Serverless API with Lambda + API Gateway

Goal: create a tiny API endpoint (e.g., /hello) without managing servers.

Steps:

Create a Lambda function (Node/Python)
Expose it via API Gateway
Test it with curl/Postman

6. Training and certifications

If you want a structured path:

AWS Skill Builder (official training)
AWS Docs (learn service-by-service)
YouTube channels / labs / hands-on projects

A common first cert:

AWS Certified Cloud Practitioner (CLF)

7. Join the community

Learning is easier with people:

AWS re:Invent sessions (even recorded ones)
Local meetups
DEV posts / discussions / GitHub projects

8. Final tips

Go one service at a time — don’t try to learn everything.
Document your progress — keep a repo or a DEV series.
Turn things off — most surprise bills come from resources left running.
Security mindset early — IAM + least privilege always.

Conclusion

AWS is huge, but starting doesn’t have to be complicated.

If you focus on the core services and build 1–2 small projects, you’ll quickly feel confident navigating AWS.

Your turn 👇

What was the first AWS service that “clicked” for you? - And what’s the best beginner project to learn it?

DEV Community: Cristian Jonhson Alvarez

How to Change a Public Repository to Private Using GitHub CLI

Prerequisite

Important Security Note

Change a Public Repository to Private

Change Visibility from the Local Repository Folder

Verify That the Repository Is Private

Open the Repository in the Browser

What Happens to Collaborators?

Useful Command Summary

Conclusion

Fixing “release version 17 not supported” on macOS for Spring Boot 3

Project context

The problem

Checking the pom.xml file

Checking the current Java version

Checking installed JDKs on macOS

Installing Java 17 with Homebrew

Configuring Java 17 temporarily

Making Java 17 permanent

Running the API again

Testing endpoints

Alternative: use Docker if you do not want to install Java 17 locally

Common errors

Error: release version 17 not supported

Maven still uses Java 11

Homebrew takes too long to install Java 17

Java 17 is installed, but Maven uses Java 11

Conclusion

Java 8 vs Java 11 vs Java 17: Which to use and why it matters in real-world projects

1. Why Compare Java 8, 11, and 17?

2. Quick Summary

3. Java 8: The Great Modern Leap

Main Features of Java 8

Example before Java 8

Example with Java 8

4. Stream API in Java 8

5. New Date API in Java 8

6. Java 11: A Cleaner Version Ready for Services

Main Features of Java 11

7. HTTP Client in Java 11

How to Create a Pull Request from the Terminal Using GitHub CLI

Prerequisites

1. Create a Feature Branch

2. Make Your Changes

3. Push the Branch to GitHub

4. Create the Pull Request

Option 1: Explicit Branch Names

Option 2: Automatically Detect the Current Branch

Option 3: Interactive Mode

Option 4: Open GitHub's PR Form in Your Browser

5. View the Pull Request

Optional: Merge the Pull Request

Complete Example

Why Use GitHub CLI for Pull Requests?

Conclusion

Most beginners misuse these Git branch commands: main, checkout -b, switch -c, and push -u explained

Why these Git commands confuse so many beginners

The real meaning of git branch -M main

What about master?

Better option for brand new repos

git checkout -b vs git switch -c: same result, different philosophy

Classic Git style

Modern Git style

Because checkout does too much

Which one should you use?

Why git push -u origin feature/inicial is more important than people think

1) Pushes the branch to the remote

2) Sets upstream tracking

The workflow most beginners actually need

Can you do this with gh?

What gh does well

What you should still do with Git

Where gh becomes really useful again

The mistake many people make

Final takeaway

Quick command summary

What do you prefer in your daily workflow: git checkout -b or git switch -c?

Reset, revert, and reflog: the ultimate guide to undoing commits without losing your repo

The real-world scenario

The real meaning of `git branch -M main`

What about `master`?

`git checkout -b` vs `git switch -c`: same result, different philosophy

Because `checkout` does too much

Why `git push -u origin feature/inicial` is more important than people think

Can you do this with `gh`?

What `gh` does well

Where `gh` becomes really useful again

What do you prefer in your daily workflow: `git checkout -b` or `git switch -c`?

Option A: `reset` (rewrites history)

Option B: `revert` (does NOT rewrite history)

2) Recover commits after `reset --hard` with `reflog`