Git Bash Commands for Beginners

As a newbie developer fresh out of an intensive BootCamp at ALX-Africa, I am committing to sharing what I have learned in the past year and a few months to make it easier for those pivoting into tech.

Immediately after joining the SE program at ALX, we were introduced to IDEs such as Emacs and Vim. I decided to settle for the latter. As if that wasn’t enough to make us the coding gods we were seeking to be, we got introduced to the power of version control systems, specifically Git.

There is no doubt that navigating Git Bash, the command-line tool that lets you interact with Git, can be intimidating at first, but it’s an essential skill for developers. Git Bash brings the power of Git to your fingertips, and mastering a few basic commands can make a world of difference in managing your code effectively. Here’s a guide to help you get comfortable with Git Bash.

In this short blog post, I share with you the most important git bash commands and other information so that you can streamline your development process.

1. Setting Up Your Git Environment

Before jumping into commands, it’s essential to set up Git Bash with your identity:

git config — global user.name “Your Name”
git config - global user.email "youremail@example.com"

This command tells Git who you are, which is crucial for tracking contributions.

2. Starting a New Git Repository

The first step in any project is to create a Git repository:

git init

3. Checking the Status of Your Repository

To view changes in your project directory, use:

git status

When you use this command, Git will display the files that have been modified, added, or deleted. This is a great way to keep track of what you’ve changed before committing.

4. Adding Changes to the Staging Area

Once you’ve made changes, you need to add them to the staging area. This prepares your files for the next commit.

git add filename

If you want to add all the changes to make them ready for a commit, you should use:

git add .

5. Committing Your Changes

When you’re ready to save your changes, commit them with a meaningful message:

git commit -m “ Write Your commit message here”

Remember: Each commit should capture a specific logical change to your codebase, helping you keep a clean history.

6. Viewing Commit History

To see the history of all commits in your project, use:

git log

For a more concise log with just the commit message and hash, use:

git log –oneline

7. Creating and Switching Branches

Software engineering is about collaborating. You will need pair programming soon enough as you begin spreading your wings to scale through the SE career.

Branches allow you to work on new features or bug fixes without affecting the main codebase. To create a new branch, use the command:

git branch branch_name

To switch to the new branch, use this command:

git checkout branch_name

Alternatively, you can also create and switch in one go:

git checkout -b branch_name

Here, The -b flag tells Git to create a new branch. If the branch already exists, Git will return an error, so this command is used only for creating new branches.

8. Merging Branches

Once you’ve finished working on a feature branch, merge it back into your main branch:

Switch to the branch you want to merge into (e.g., main or master):

git checkout main

Then merge:

git merge branch_name

9. Cloning a Repository

If you want to contribute to an existing repository, clone it to your local machine, use this command:

git clone repo_url

Replace repo_url with the repository’s actual URL.

10. Pulling Changes from a Remote Repository

To stay updated with the latest changes in a shared project, pull updates:

git pull

11. Pushing Changes to a Remote Repository

When you’re ready to share your changes, push them to the remote repository:

git push origin branch_name

This sends your commits to the specified branch in the remote repository.

12. Stashing Changes

If you need to switch branches but have uncommitted changes, stash them temporarily:

git stash

You can retrieve these changes later with:

git stash pop

13. Resolving Conflicts

Conflicts can happen when working on team projects. Git will notify you of conflicts, and it’s up to you to manually resolve them by editing the conflicted files. After resolving, add the file and commit the changes:

git add conflicted_file
git commit -m "Resolved merge conflict in conflicted_file"

A Few Insights on Commit Messages

Writing clear and meaningful commit messages is essential for good version control practices. It’s not just about keeping track of changes; it’s about making your codebase understandable for others (and even your future self!).

I was always sucking at writing commit messages until I read a few resources. Here are some insights I have gathered that can help you write effective commit messages:

1. Use the Imperative Mood

Write commit messages as if you’re giving a command. For instance:

• “Add login functionality.”

• “Fix bug in user profile”

Using the imperative mood helps maintain consistency and makes it clearer what each commit accomplishes. Think of it as “This commit will…”

2. Keep it Concise and Descriptive

Commit messages should give an idea of what changed without being too wordy. Aim for around 50 characters in the first line.

· “Refactor homepage layout.”

· “Update API documentation”

Here is an example that is not concise and descriptive

· “Worked on changing the layout and improving API docs.”

3. Use Capitalization and Punctuation Consistently

Start your message with a capital letter, and avoid punctuation at the end of the subject line. It keeps things tidy:

· “Fix the issue with page loading speed.”

This here is BAD practice:

“fix the issue with page loading speed.”

4. Include Details for Complex Changes

If your commit involves multiple steps or is complex, provide more detail after the first line. Use this format:

Add user authentication feature

Implemented JWT for secure login and registration.
Adjusted middleware to validate tokens on protected routes.

Explanation: The first line provides a high-level summary, while the additional lines (separated by a blank line) explain specific changes. This makes it easy for others to understand the context without wading through your code.

5. Use Prefixes for Structure (Optional)

In many teams, developers use prefixes to categorize commit types. Common ones include:

• feat: for new features, e.g., feat: add password reset functionality.

• fix: for bug fixes, e.g., fix: correct alignment issue in navbar.

• docs: for documentation changes, e.g., docs: update README with setup instructions.

• refactor: for code refactoring, e.g., refactor: improve database query efficiency.

• test: for testing updates, e.g., test: add unit tests for login flow.

Using these prefixes keeps commit history clear and makes it easy to scan for specific types of changes.

6. Make It About the “What” and “Why,” Not the “How”

The commit message should focus on what changed and why you made that change rather than describing every line of code. For example:

• “Fix login bug causing incorrect redirect.”(GOOD)

• “Change the if statement in auth.js to check user roles.” (BAD DON’T DO)

This way, the message explains the outcome or intent of the code change rather than the mechanics.

Think of commit messages as part of your project’s documentation. A few months from now, well-written commit messages will help you (and your teammates) understand why a change was made, saving time and reducing confusion.

Alternatives Ways to Push Code to GitHub

When it comes to pushing changes to a remote repository in Git, there are a few alternative commands and approaches you can use depending on your workflow and goals. Here are some useful alternatives to the standard git push origin branch_name command:

1. Pushing with Upstream Tracking

Using -u (or — set-upstream) sets an upstream branch for your local branch, allowing you to simply use git push in the future without specifying the remote or branch name. This is ideal if you’ll be frequently pushing to the same branch.

git push -u origin branch_name

After setting the upstream, subsequent pushes can be done with just:

git push

2. Pushing All Branches

If you have multiple branches you want to push at once, use the — all option:

git push — all origin

This command will push all branches to the specified remote repository.

3. Pushing with Force (Use with Caution)

If you’ve rewritten history (e.g., using git rebase or git commit — amend), Git will prevent you from pushing to avoid conflicts. To override this, use — force or -f, but be careful as this can overwrite the remote history:

git push -f origin branch_name

To minimize risk, consider using — force-with-lease, which only forces the push if others haven’t modified the remote branch since your last pull:

git push — force-with-lease origin branch_name

4. Pushing Tags

If you’re using tags to mark specific commits (e.g., for versioning), you can push tags separately:

• Single Tag:

git push origin tag_name

• All Tags:

git push –tags

This will push all tags from your local repository to the remote.

5. Pushing to a Different Remote

If you have multiple remotes (e.g., origin and upstream), you can specify which remote to push to:

git push upstream branch_name

This allows you to push changes to a different remote repository without affecting the main remote.

6. Pushing to a Different Branch Name

If you want to push to a branch with a different name on the remote (e.g., pushing dev locally to main remotely), you can specify both branch names:

git push origin local_branch:remote_branch

Here is an example:

git push origin dev:main

This will push your local dev branch to the remote main branch.

7. Dry Run for Pushing

If you’re unsure about what will be pushed, you can run a dry run to preview the push without actually sending anything:

git push — dry-run origin branch_name

This is useful for checking what would be pushed to the remote repository, especially if you’re working in a team and want to avoid conflicts.

8. Push Only Specified Commits (Push by SHA)

If you want to push only a specific commit (identified by its SHA hash) to the remote, you can use the commit hash:

git push origin <commit_hash>:branch_name

This approach is less common but can be helpful in specific workflows, like pushing a single change for testing.

Pushing changes using these methods depends on your needs, whether you’re managing multiple branches, collaborating with others, or maintaining careful control over your push history.

Remember to use force options with caution and consider your team’s workflow to avoid overwriting each other’s work!

To Sum Up

And that’s it for the basic git bash commands.

If you are struggling with learning Git Bash commands, I can relate — I was there myself. It might seem overwhelming initially, but each command contributes to a more organized and efficient workflow. No need to cram them; you soon enough get good at it and have the option of referring to documentation each time when unsure about the command to use.

If you got this far, you now have the foundational knowledge needed to collaborate with others confidently. There are more git bash commands to streamline your workflow, but with the basics in mind, you can do wonders with git and GitHub.

Remember, version control is a skill that grows with practice — so don’t be afraid to experiment and explore!