Version Control and Developer Tooling Questions

Direct answer

The three reset modes differ in how much of git's areas they touch: the commit history that HEAD points to, the staging area (also called the index), and your working directory files. --soft only moves HEAD; --mixed, the default, also resets the staging area; --hard resets all three, including discarding uncommitted changes in your working files. Use reset freely on commits that are still local and unpushed; once a commit is shared with others, use git revert instead, which undoes it with a new commit rather than rewriting history anyone else might already have.

Structured elaboration

# --soft: move HEAD back one commit, keep everything staged
git reset --soft HEAD~1

# --mixed (default): move HEAD back, unstage, but keep the changes in your files
git reset HEAD~1

# --hard: move HEAD back and discard the changes entirely (use with real caution)
git reset --hard HEAD~1

Worked example

Concrete scenario for --soft: you just committed, but the message was wrong, or you want to fold it into your next commit. git reset --soft HEAD~1 undoes just the commit; the file changes stay fully staged, so you can immediately commit again with a better message, or keep editing and commit once when ready:

git reset --soft HEAD~1
# fix whatever needed fixing
git commit -m "Corrected commit message"

When the bad commit has already been pushed and others may already have pulled it, use revert instead, which creates a new commit that applies the inverse change rather than erasing history:

git revert <bad-commit-sha>
git push origin main

Trade-offs and pitfalls

git reset --hard on a commit that's already been pushed and pulled by someone else doesn't undo it for them, it only rewrites your own local history; if you then push, you're forcing a history rewrite onto a shared branch, exactly the scenario revert exists to avoid. --hard is the one mode with real data-loss risk, since uncommitted working-directory changes are discarded, not just unstaged, so it's worth a git status check before running it. A reverted commit still exists in history, visible, alongside its own new revert commit, which is actually a feature for shared branches: it keeps an honest record of what happened rather than pretending the mistake never occurred.

Direct answer

git merge combines two branches by creating (or fast-forwarding to) a commit with two parents, preserving the exact history of what actually happened, including when the branches diverged. git rebase rewrites your branch's commits one by one on top of a new base, producing a linear history as if you had started your work from the target branch's latest commit. Use merge for shared or public branches, and to preserve the true chronological record; use rebase to clean up your OWN not-yet-shared feature branch before it is reviewed or merged.

Structured elaboration

• Effects on commit history: merge adds a merge commit (an extra node with two parents) and leaves the branch's original commits untouched, so the history literally shows when and how two lines of work joined. Rebase replaces the branch's original commits with new ones (same content, new hashes and a new parent), producing a straight line, at the cost of that history no longer reflecting when the work actually diverged.
• Conflict resolution: merge resolves all accumulated conflicts once, in a single merge step. Rebase can require resolving the same conflict repeatedly, once per replayed commit, if several commits touch the same lines. That is more tedious on a long-diverged branch, but each individual conflict is scoped to a smaller, more understandable diff.
• Code review ergonomics: rebasing a branch that is already under review invalidates the diff reviewers were looking at (new commit hashes), and a force-push can silently disconnect review comments from the old commits on some tools. Teams commonly agree "no rebasing mid-review" for this reason, but DO rebase (or otherwise clean up) a branch BEFORE opening the pull request, so what reviewers see is already a clean, logical set of commits.
• Pitfalls: rebase requires a force-push (git push --force-with-lease, never a bare --force) to update a branch whose history you rewrote. That is dangerous on any branch someone else might also be working from, since it can strand or silently discard their local commits if they later force-push over yours. Never rebase a branch other people have already pulled and built work on top of, that is the one hard rule.

Worked example

This is a real, reproducible git session, run exactly as shown; your own commit hashes will differ every time you run it, since hashes are content- and timestamp-derived, but the shape of the history will match.

$ git init -q && git config user.email you@example.com && git config user.name You
$ echo line1 > file.txt && git add file.txt && git commit -qm "initial commit"
$ git checkout -qb feature/login
$ echo "login work 1" >> file.txt && git commit -qam "add login step 1"
$ echo "login work 2" >> file.txt && git commit -qam "add login step 2"
$ git checkout -q main
$ echo "main hotfix" >> readme.txt && git add readme.txt && git commit -qm "hotfix on main"

$ git log --all --oneline --graph
* f6a4e94 add login step 2
* 3f1b249 add login step 1
| * b203e9a hotfix on main
|/
* d00f83b initial commit

Merge:

$ git checkout -qb merge-demo main && git merge --no-edit feature/login
$ git log --oneline --graph
*   8d0f96b Merge branch 'feature/login' into merge-demo
|\
| * f6a4e94 add login step 2
| * 3f1b249 add login step 1
* | b203e9a hotfix on main
|/
* d00f83b initial commit

Rebase, from a fresh branch off feature/login:

$ git checkout -qb rebase-demo feature/login && git rebase main
$ git log --oneline --graph
* 80d6191 add login step 2
* 229c32c add login step 1
* b203e9a hotfix on main
* d00f83b initial commit

The merge history keeps both lines of development visible with a two-parent commit; the rebase history is a single straight line as though "login step 1" and "login step 2" were written after the hotfix.

Trade-offs & pitfalls

"Lost commits" after a rebase usually means a teammate had local commits based on the OLD (pre-rebase) branch tip, and either force-pushed over the new history or kept building on a branch tip that no longer exists remotely. --force-with-lease (which refuses to push if the remote moved since you last fetched) is a safeguard against silently clobbering that, not a substitute for the underlying rule: do not rebase a branch others have already pulled.

Direct answer

grep -rlI 'MaxSessions' /etc 2>/dev/null searches recursively, prints only the names of files that contain a match, and skips binary files it encounters along the way.

Structured elaboration

grep -rlI 'MaxSessions' /etc 2>/dev/null

Key points:

• -r: recurse into subdirectories.
• -l: print only the names of files that contain a match, not the matching lines. This is what you want when the question is "which file," and it also avoids printing (and discarding) potentially huge amounts of matching text.
• -I: treat binary files as if they had no match, so grep silently skips them instead of printing noise like "binary file matches."
• 2>/dev/null: /etc contains files only root can read on most systems. This suppresses the "Permission denied" stderr noise so it does not clutter real results. Run it once without the redirect first to see what is actually being denied, so you are not silently missing files you do have permission to read.

Worked example

$ mkdir -p mock_etc/nginx mock_etc/ssh mock_etc/random
$ echo "listen 80;" > mock_etc/nginx/nginx.conf
$ printf 'MaxSessions 10\nPermitRootLogin no\n' > mock_etc/ssh/sshd_config
$ printf '\x00\x01binarydata\x02MaxSessions' > mock_etc/random/blob.bin

$ grep -rlI 'MaxSessions' mock_etc
mock_etc/ssh/sshd_config

This is a small reproducible stand-in for /etc, not the real directory (whose contents differ by machine). It was run exactly as shown: the text file containing the directive is reported by name, and the binary file that happens to contain the same byte sequence is silently skipped because of -I.

Trade-offs & pitfalls

• Complexity is one walk over every file under the directory, proportional to total bytes searched under the tree. Instant for something as small as /etc; searching a whole filesystem this way would call for scoping the search or pruning directories you do not care about with find.
• -r follows symlinks that are files, but does not follow symlinks to whole directories by default. Use -R (dereference-recursive) only if you specifically need to walk into symlinked directories, and be aware that can cause an infinite loop on a badly set up filesystem.
• If the pattern contains characters the shell would interpret (*, $, or a leading -), quote it, and for anything starting with a dash use grep -e '-mypattern' so grep does not mistake it for a flag.
• A common first instinct is piping through a second grep for the filename; -l does the job in one pass without printing and discarding every matching line, which matters once files are large.

Direct answer

Use grep -ci 'error' /var/log/app.log for a count, and grep -in -C 3 'error' /var/log/app.log to show each match with 3 lines of context before and after, both case-insensitive.

Structured elaboration

# how many matching LINES contain "error" (case-insensitive)
grep -ci 'error' /var/log/app.log

# show each match with 3 lines of context before and after, with line numbers
grep -in -C 3 'error' /var/log/app.log

Key points:

• -i: case-insensitive, matches ERROR, error, and Error alike.
• -c: prints a single number, the count of matching lines, not the count of occurrences.
• -C 3: 3 lines of context both before and after each match (equivalent to combining -A 3 and -B 3).
• -n: prefixes each printed line with its line number. Matched lines are marked with :, context lines with -, which is how you tell a real match from surrounding context in the output.

Worked example

$ cat app.log
2026-08-10 10:00:01 INFO starting service
2026-08-10 10:00:02 INFO connected to db
2026-08-10 10:00:03 error timeout connecting to cache
2026-08-10 10:00:04 INFO retrying
2026-08-10 10:00:05 INFO retry succeeded
2026-08-10 10:00:06 ERROR failed to write to disk
2026-08-10 10:00:07 INFO cleanup
2026-08-10 10:00:08 INFO shutdown requested

$ grep -ci 'error' app.log
2

$ grep -in -C 3 'error' app.log
1-2026-08-10 10:00:01 INFO starting service
2-2026-08-10 10:00:02 INFO connected to db
3:2026-08-10 10:00:03 error timeout connecting to cache
4-2026-08-10 10:00:04 INFO retrying
5-2026-08-10 10:00:05 INFO retry succeeded
6:2026-08-10 10:00:06 ERROR failed to write to disk
7-2026-08-10 10:00:07 INFO cleanup
8-2026-08-10 10:00:08 INFO shutdown requested

This was run exactly as shown. Notice the two matches (lines 3 and 6) are only 3 lines apart, so their ±3-line context windows overlap and grep prints one continuous 8-line block rather than two separate excerpts.

Trade-offs & pitfalls

• Complexity is a single linear pass over the file, proportional to file size. Fine as a one-off on a large log; a very hot, repeated version of this query is where you would reach for a log aggregator instead of re-running grep constantly.
• -c counts matching lines, not occurrences: a line containing "error" twice still counts once. To count actual occurrences, use grep -oi 'error' app.log | wc -l.
• If the log contains stray binary-looking bytes (for example from a crashed writer), grep may report "binary file matches" instead of printing the lines. Force text handling with grep -a.

Direct answer

There is no single right answer, only a trade-off across developer ergonomics, auditability, and offline development, and the right choice scales with team size. For a small team, an encrypted-in-repo file or a lightweight secrets-manager CLI beats a shared plaintext .env. For a team large enough that access needs to be revocable per person, a real secrets manager earns its setup cost, because auditability (knowing exactly who has fetched what, and being able to cut off one person's access without rotating the underlying secret) is a property nothing else on this list gives you.

Structured elaboration

Keep a documented, deliberate offline fallback (a clearly-labeled stub or a short-lived cached credential) for anyone stuck without network access. A workflow that hard-fails without connectivity gets worked around with a hand-copied plaintext file the first time someone is stuck at an airport, quietly recreating the exact risk the tool was meant to remove.

Worked example

A team of six starts with a shared .env.example and real values pasted into a team chat thread. When a contractor's engagement ends, the team realizes it would need to rotate every secret in that thread, because there is no way to know what the contractor still has a copy of; this is exactly the failure mode auditability buys back. They migrate to a lightweight secrets-manager CLI: each developer authenticates once, and a local wrapper script pulls current secrets into environment variables at the start of a dev session, fetched fresh each time, never written to disk in plaintext. Revoking the departed contractor's access afterward is a single action in the secrets manager, no rotation needed, because the underlying secret's value never left the manager's control in a form the contractor could independently retain.

Trade-offs and pitfalls

• A secrets-manager workflow is only as strong as its offline story; if the dev server hard-fails without network because it can't reach the vault, developers will improvise a local plaintext copy the moment connectivity is bad, quietly recreating the exact risk the tool was meant to remove.
• Encrypted-in-repo tools solve distribution but not real-time revocation: decrypting a secret onto a developer's laptop means it exists in plaintext there from that point on, so rotating the underlying value is still required if that laptop is compromised or that person leaves.
• Auditability is a property of the system, not of policy alone. Asking people not to share secrets over chat, without a technical alternative that is actually easier than chat, will not hold up under deadline pressure; the ergonomics and the security property have to point the same direction or the security property loses.