Git

Merge and rebase integrate work with different consequences for commit identity and ancestry. A merge normally retains the existing commits and joins their histories; a rebase transplants selected changes onto another base. The choice is not only how a graph looks. It affects review references, conflict handling, signatures, and collaborators who already depend on the old commits. Decide using the repository’s workflow and the actual branch relationships. ...

A merge connects histories and records a resulting project snapshot. In an ordinary merge of two diverged branches, the new commit names both prior tips as parents. Those parent links keep the earlier commits reachable, but they do not prove that the resulting files retain every intended behavior. Merging is both a graph operation and a content decision; verifying only one of those aspects leaves important mistakes undetected. ...

Git stash records selected uncommitted work so a checkout can temporarily return to an earlier committed state. It is useful for a short interruption, but neither saving nor restoring is an unconditional promise about every file in the directory. The important questions are what was included, which base the work came from, what state the destination now has, and when the saved entry can be removed. ...

Cherry-pick applies the change introduced by a selected commit to the current line of development. It is useful for a targeted backport when an older release needs one fix without the rest of a development branch. It does not move or delete the source commit, and it does not establish a merge relationship with the source branch. The target result must be reviewed as a change in its own environment. ...

Git ignore rules influence which untracked paths ordinary discovery and add operations consider. They are useful for generated files, editor state, and local configuration. They do not create an access-control boundary, remove a file already in the index, or erase earlier commits. Treat the ignore file as a project convention with observable matching rules, not as a guarantee that a sensitive file cannot enter history. ...

A hotfix need not displace unfinished feature work from its directory. A linked worktree can start from a chosen release commit while the original directory retains its staged changes, unstaged edits, and untracked files. The workflow succeeds when the fix is tested on the correct baseline and the original work remains intact. Merely creating a second folder does not establish either result. ...

Bisection answers a precise historical question: within selected history, where does a reproducible observation change from good to bad? It does not identify a root cause merely by naming a commit. The search depends on correct endpoint labels and consistent intermediate decisions. Treat the reported boundary as evidence to inspect, then confirm the behavior on both sides and explain the change that accounts for it. ...

A linked worktree gives one Git repository another working directory, with its own checked-out state. That lets a feature, release, or review stay open alongside other work without repeatedly replacing the same files. The useful boundary is separate working files and staging, not complete isolation. Objects, many references, and ordinary repository configuration are shared, so operations need to respect both the local workspace and the common repository. ...