42 Git Questions Answered
Tags: git
Published: 2019-10-17 15:07:01

---
title: '42 Git Questions Answered'
published: true
description: 'Answers to 42 Git questions asked during a recent training I lead to guide a development team from git init to Git Master.'
tags: git
canonical_url: https://jasonmccreary.me/articles/42-git-questions-answered/
cover_image: https://thepracticaldev.s3.amazonaws.com/i/n80bw619a9iytorw3tfb.jpg
---

1. What is your favorite Git command?

    > I am a sucker for `git add -p`. This adds changes in "patch mode" which is a built-in command line program. It iterates over each of my changes and asks me if I want to stage them?

    > This command forces me to **slow down and review my changes**. Too often as developers we rush this part thinking the work is done. I can't tell you how many times I've run `git add .` in a hurry to later realize I committed "scratch" files or debug statements.


2. Why do you prefer using Git from the command line?

    > As developers, we're already using the command line for so many other things. Why not for Git as well?

    > In addition, Git has a very small command set. One that is pretty easy to learn as a developer and will improve your development workflow by using it directly.


3. How can we use `stage` command?

    > `stage` is a built-in alias for `add`.


4. How can I save the changes in a branch and checkout to other branch?

    > So you may use `git stash` to temporarily store your changes or make a WIP commit. The goal is to have a clean working index.

    > Personally, I prefer working with WIP commits rather than `stash`. I find them easier to reference and potentially share.


5. When should I use `git stash`?

    > I like to use `stash` for quickly getting the "working index" **clean**.


6. How do I see how to use a Git command?

    > Use the `--help` option for any command. Example, `git stash --help`.


7. What is "git flow"?

    > git flow is a [branching strategy](https://nvie.com/posts/a-successful-git-branching-model/) using multiple "long-lived" branches which mirror the software development lifecycle. Changes are merged between these branches as work is needed.



8. What is "GitHub Flow"?

    > Basically GitHub Flow is a branded name for a `master`/feature branch workflow. GitHub has formalized this into a process using their toolset shown in this [visual tutorial](https://guides.github.com).


9. Which branching strategy do you prefer?

    > I've worked on hundreds of Git projects and I will say most reach for "git flow". Only a a handful of these projects ever *needed* that strategy. Often because it was versioned software.

    > The `master`/feature branching strategy is much easier to manage, especially when you're just starting out. And it's very easy to switch to "git flow" if needed.



10. What was the `git open` command you used?

    > It's a separate command and available as an [npm package](https://www.npmjs.com/package/git-open).


11. How can you reset a branch when there are files that were added in other branch but still appear as untracked or modified in your working branch?

    > This is often the result of switch branches when the "working index" is **unclean**.

    > There's no built in way to correct this with Git. I normally avoid this by ensuring my prompt has a "status" indicator and running commands like `git status` anytime I change a branch.

    > These habits give me an opportunity to catch this early so I can either `stash` or `commit` those changes working on a new branch.


12. How can I rename a branch ?

    > `git branch -m current-branch-name new-branch-name`


13. How I can use `cherry-pick`?

    > `git cherry-pick [reference]`. Remember this is a **reapplying** command, so it will change the commit SHA.


14. If I make a revert from a branch and (for example `HEAD~3`), is it possible to go back to `HEAD` again (like a recovery of your last updates?

    > In this scenario, I would immediately undo the `revert` commit (which is the `HEAD` commit) by running `git reset --hard HEAD~1`.


15. When use `git pull` and `git fetch`?

    > `git pull` will **download** the commits to your current branch. Remember, `git pull` is really the combination of the `fetch` and `merge` commands.

    > `git fetch` will **retrieve** the latest references from a remote.

    > A good analogy is with a podcast player or email client. You might retrieve the latest podcasts or emails (fetch), but you haven't actually downloaded the podcast or email attachments locally yet (pull).


16. Why sometimes we need use `--force` to push the changes of a rebase?

    > `rebase` is a command which may **reapply** commits which changes their SHA1 hash. If so, the local commit history will no longer align with its remote branch.

    > When this happens you will get a **rejected** `push`. **Only when rejected** should you consider using `git push --force`.

    > Doing so will overwrite the remote commit history with your local commit history. So always slow down and **think about why** you need to use `--force`.


17. Can you use a branch to merge multiple branches and then send this branch to master?

    > Absolutely. It's common under most of the Git workflows for branches to accumulate changes from multiple other branches. Ultimately these branches are "promoted" into the main branch.


18. Should I do a rebase from a very old branch?

    > Only if you have to.

    > Depending on your workflow, it may be possible to merge a stale branch into your main branch.

    > If you need to bring a branch up-to-date, I prefer `rebase`. It provides a cleaner history of only your changes instead of commits from other branches or merges.

    > However, while always possible, using `rebase` may be a painful process since each of your commits are reapplied. This may lead to multiple conflicts. If so, I normally `--abort` the `rebase` and use `merge` instead to resolve all the conflicts once.




19. When using `rebase -i`, what's the difference between `squash` and `fixup`?

    > Both `squash` and `fixup` combine two commits. `squash` pauses the rebase process and allows you to adjust their commit message. `fixup` automatically uses the message from the first commit.


20. Often when I `rebase` my feature branch with `master`, for each commit I need resolve conflicts?

    > Yes. Since the changes from each commit is **reapplied** during `rebase`, you have to resolve any conflicts as they happen.

    > This means a commit conflicts early in the process, or if you resolve it incorrectly, it's likely many of the following commits will conflict as well.

    > To limit this, I often use `rebase -i` to first condense my commit history so it is easier to work with.

    > If there are still conflicts across many commits, I may use `merge` instead.


21. Is necessary update my branch with master before merge it with master?

    > Depending on your workflow, it may be possible to merge a stale branch into your main branch.

    > If your workflow uses "fast-forward" only merges, then it will be necessary to update your branch before merging.


22. Do you recommend use GitKraken?

    > I am an advocate for using Git from the command line. I find this keeps me in full control of managing changes, as using commands to improve my development process.

    > Of course, certain visual actions like managing branches and viewing file differences will always be better in a GUI. Personally, I find viewing such things in the browser during the merge process to be enough.


23. Could you do an `--amend` of a commit when it already was pushed?

    > Yes. However, you would not want to amend a commit after it is merged into another branch since `--amend` changes the commit.


24. When I know I will work on something for a while, should I open a _pull request_ for each change or a complete pull request for all the work?

    > You normally want to open a pull request for all the work.

    > However, if you are working on something for a long time. It might be beneficial to merge smaller changes along the way. Doing so will prevent dependencies on your branch or staleness.

    > This will depend on the type of changes you are making.


25. Is it good practice make a `release` branch before merge a branch to `master`?

    > This depends heavily on your deployment process. Creating a `release` branch can be beneficial to group together work from multiple branches and test them as a whole before merging them into your main branch.

    > Since the source branches remain separate and unmerged, you will have more flexibility in the final merge.


26. How to take just some commits from `master`? Let's say I don't want to take the last commit but do a rebase.

    > Assuming `master` is your main branch, you don't want to selectively pull commits from its history. This will cause conflicts later.

    > You will want to `merge` or `rebase` your branch will all the changes from master.

    > For pulling select commits from a branch other than your main branch, you can use `git cherry-pick`.


27. Are there some special themes that I can set up on my terminal?

    > I cover [configuring and customizing your terminal](https://gettinggit.com/everyday-git/terminal-tweaks-for-git) in Getting Git.


28. Which option is best instead of use the command `git push --force`?

    > There really isn't an alternative to `git push --force`.

    > With that said, if you properly update your branch with `merge` or `rebase` you should not need to use `git push --force`.

    > Only when you have run commands which change your local commit history from the history you previously shared should `git push --force` be required.


29. When I select `drop` during `git rebase -`, is the code related to that commit deleted?

    > Yes!

    > To revive this code, you will need to find a state prior to the `rebase` from the `reflog`.


30. How can we track automatically a remote branch?

    > Normally branch tracking is set up automatically by Git when you `checkout` or create a branch.

    > If not, you can update this the next time you push with: `git push -u remote-name branch-name`.

    > Or you can set it explicitly with:`git branch --set-upstream-to=remote-name/branch-name`



31. Is a best practice `rebase` a branch before updating it?

    > I believe so, simply for the reason organizing or collapsing your commits with `git rebase -i` first gives you more context during the update process.


32. Is there a way to split a commit into more commits (something inverse to `fixup`/`squash`)?

    > You could use the `exec` command during the `rebase -i` process to attempt to modify the working index and split up changes.

    > You can also use `git reset` to undo recent commits and place their changes in the working index to then separate their changes into new commits.


33. Is there a way to go or see a commit that was fixed up?

    > Not the previous commits. You can using `git show` to see the changes within the new commit?



34. What does `rebase --skip`?

    > This tells `rebase` to not apply the current changes during the rebase process.


35. How can I remove remote branches?

    > You can remove a remote branch by pushing "nothing" with:
  `git push origin :branch-name-to-remove` or using the `-d` option with: `git push -d origin some-other-branch-2`.

    > To remove local reference to remote branches, you can run: `git remote prune origin`.

36. What's the difference between `checkout` and `reset`?

    > Both of these commands can be used to undo changes. `checkout` is arguably more robust as it allows you to not only undo current changes, but also undo a set of changes by retrieving an older version of a file.

    > `reset`, by default, works more with changing the state of changes within the working index. As such, it really only deals with the current changes.

    > I prefer `reset`. The wording makes more sense for the action, which is often to change the state or discard current changes. I tend to reserve `checkout` for switching branches and the rare occasion of restoring an old version of a file.


37. What commands should I avoid using in normal workflow?

    > Anything that could be destructive to your history, for example:

    > - `git push origin master -f` (NEVER)
    > - `git revert` (on a feature branch)
    > - `git cherry-pick` (changes from `master`)

    > Under a normal workflow, I try to avoid using `git merge` directly as this is often built into the process through pull requests.


38. If I have a branch (B) that points to other branch (A) and I have another branch (C) which needs code from (A) and (B) and master which process must follow to have (C) updated?

    > Interesting. This depends on a few things…

    > Are `A` and `B` something that can be merged into `master`? If so, you could merge `A` and `B` into `master`, and then update `C` with the latest changes from `master`.

    > If not, you may be able to simply merge `B` into `C` since it contains the changes from `A` already.

    > In the extreme case, you could merge `A`, `B`, and `master` into `C`. However, it's likely the order of merging would matter to avoid conflicts.


39. What are some of the aliases you use?

    > I [don't alias Git commands](https://jasonmccreary.me/articles/stop-aliasing-core-git-commands/) often. Especially not core commands. I find doing so creates confusion, especially as a trainer.

    > With that said, I do have a few aliases for common commands or commands I use with a lot of options:

    > ```sh
    > alias.unstage reset HEAD --
    > alias.append commit --amend --no-edit
    > alias.wip commit -m "WIP"
    > alias.logo log --oneline
    > alias.lola log --graph --oneline --decorate --all
    > ```

40. What are some lesser known Git commands?

    > `git bisect` is a life-saver for finding an existing bug in the code. While I've only used it a few times, it has been impressively precise and saved hours of looking for a needle in a haystack.

    > `git archive` is another nice one for packaging up a set of changes. This can be helpful for sharing work with a third-party or mico-deployments.

    > `git reflog` is probably known, but worth mentioning as it provides a nice way to "undo" commands when things go wrong.


41. Can you recommend some books for learning more about Git?

    > Sure. I recommend reading at least the first 3 chapters of [Pro Git](https://git-scm.com/book/en/v2). I have done so a few times over the years and always learn something.

    > Of course, I shamelessly recommend [Getting Git](https://gettinggit.com). My video course covering the basic and advanced usage of all Git commands from the command line.

42. What if I have more questions?

    > Awesome. Send them [to me on Twitter](https://twitter.com/gonedark).



<small>* _Photo by [Bob Jansen](https://unsplash.com/@jansn?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)_</small>