Skip to main content

Recap and FAQ

Summary: this final lesson condenses the previous 5 into one picture, answers the 12 most frequent practical questions from beginners (useful both to clear the last doubts and for Google search visibility), and points you towards what comes next.

1. What you know now​

You are not yet an autonomous Git user. But you know exactly how things work in a team that does them well. That is half the journey.

2. FAQ · the 12 practical beginner questions​

2.1 I made a bad commit. Can I undo it?​

Yes, almost always. Three cases:

  • The commit is not pushed yet — you can modify or delete it locally, nobody will know.
  • The commit is pushed but nobody has fetched it — you can delete it and force-push (dangerous, avoid if you are not alone).
  • The commit is pushed and integrated — you can make a new commit that cancels the old one (git revert). The history remains, but the effect is neutralized.

Golden rule: never modify an already shared commit. Always create a new one that fixes it.

2.2 Can I delete a branch?​

Yes, without hesitation, once it has been merged or abandoned. Two commands are enough:

  • git branch -d branch-name — deletes the local branch.
  • git push origin --delete branch-name — deletes the remote branch.

On GitHub, a "Delete branch" button appears automatically after a PR is merged.

2.3 What is git stash and what is it for?​

git stash is a temporary drawer. It lets you put away your in-progress changes without committing them, to switch context quickly (for example, someone has an urgent bug to fix and you have not finished your work).

Once the context is done, git stash pop puts your changes back exactly where they were. It is a well-known lifesaver.

2.4 Is the famous git push --force really that dangerous?​

Yes, very. A push --force rewrites the remote history — if a colleague had fetched your branch before, their commits disappear at the next pull.

Absolute rule: never do git push --force on a shared branch (especially not main or develop). On your personal branch before review, it is acceptable — prefer --force-with-lease, a safer version that refuses if someone else has pushed in the meantime.

2.5 How do I ignore a file (password, generated file)?​

Create a file named .gitignore at the root of the project, and list the files or folders to exclude:

node_modules/
.env
*.log
.DS_Store
build/

Git will never track them. Careful: a file that is already committed keeps being tracked even if added to .gitignore — you must remove it explicitly with git rm --cached.

Best pick: the site gitignore.io automatically generates a complete .gitignore for your language (Python, Node, Java, Rust…).

2.6 How do I recover a file I deleted by mistake?​

As long as the file was tracked by Git, it is never really lost. Type git checkout HEAD -- path/to/file to restore its version from the last commit.

If the file was never committed and you deleted it, Git can do nothing — hence the importance of committing often.

2.7 What is the difference between pull and fetch?​

  • git fetch = look at what is new on the remote, without integrating anything.
  • git pull = git fetch followed by git merge → directly integrates the news.

Recommendation: prefer fetch then inspection (git log), then a conscious merge. pull is faster but sometimes surprising, especially when someone has rewritten the history.

2.8 How do I rename a recent commit?​

git commit --amend lets you modify the last commit — its message, its files, or both. It is very handy right after a typo in a message.

Careful: only --amend a commit that is not pushed yet, otherwise you break the remote history.

2.9 How many branches can I have at the same time?​

Technically, as many as you want — Git handles thousands of branches without flinching. Pragmatically, each developer works on 1 to 3 branches at a time. Beyond that, you lose track.

On a team project, the number of active branches is a good indicator: too many open branches = accumulation of unmerged work = risk of massive conflicts later.

2.10 Can I rewrite a project's history?​

Yes, with interactive rebase (git rebase -i) — you can reorder, squash, split, rename, delete commits. It is very powerful, very dangerous, and should be reserved for personal branches before sharing.

Sacred rule: never rewrite the history of a shared branch. It is like changing the past of a book after it has been distributed — readers end up with inconsistent versions.

2.11 How do I see who wrote a line of code, and why?​

git blame path/to/file displays, for each line, the commit that introduced it, its author, its date, and its message.

It is an essential tool for understanding a project's history — often a strange line becomes clear once you read the commit that created it. Modern IDEs (VS Code, JetBrains) display the blame live in the margin, called "CodeLens".

2.12 Can I use Git for something other than code?​

Yes, absolutely. Git is a file manager with history — it can version:

  • Documentation (Markdown, LaTeX).
  • Server configurations (Nginx, Apache, systemd, Ansible).
  • Manuscripts — many professional writers version their novels in Git.
  • Cooking recipes, personal notes, Unity project files…

Careful: Git is less efficient on very large binary files (photos, videos, databases) — for those, prefer Git LFS (Large File Storage) or a dedicated storage system.

3. Going further​

Three possible directions.

Direction 1 · Move to full hands-on practice (recommended)​

The Premium Git Course covers all the concepts seen here with the real commands:

  • Detailed installation and configuration.
  • The 20 essential commands with exercises.
  • Branches, merge, rebase, cherry-pick, stash, tags.
  • Conflict resolution with real-life scenarios.
  • Team workflows (GitHub Flow, GitFlow, Trunk-based).
  • Contributing to a first open source project.
  • Best practices: Conventional Commits, GPG signatures, hooks.

Count on 30 to 40 hours of structured content with exercises.

Direction 2 · Explore the adjacent building blocks​

This practical course has direct cousins in the discovery path:

Direction 3 · Contribute to your first open source project​

The best learning happens by practising on a real project. Two resources to start today:

A simple typo fix in a documentation becomes your first pull request, stress-free. The time it takes you to make that contribution will surprise you — often less than an hour.

4. One last picture to take with you​

Remember in 30 seconds​

  • You now have the complete mental map of Git in practice.
  • Recommended next step: the Premium Git Course to move on to the real commands.
  • Or open your first pull request on an open source project today — it is more accessible than you might think.

Congratulations, you have finished the Git in practice discovery course.

Ready for full mastery? Discover the Premium Git Course →

Want to take on open source? Find a first accessible ticket →

Explore the other fundamentals? See all discovery courses →

Last step: take the end-of-course quiz — five corrected and explained questions, three minutes, to check that the essentials have been acquired.