42 Git Questions Answered

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 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.

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.

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 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 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:

    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
    

1. 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.

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

   Sure. I recommend reading at least the first 3 chapters of Pro Git. I have done so a few times over the years and always learn something.

   Of course, I shamelessly recommend Getting Git. My video course covering the basic and advanced usage of all Git commands from the command line.

3. What if I have more questions?

   Awesome. Send them to me on Twitter.

* Photo by Bob Jansen

Comments

[mmirca]

Great post! For number 11 git clean might get the job done: git-scm.com/docs/git-clean

[Jason McCreary]

For sure. Good point, I'll add that as an option.

[Kobe Raypole]

Great stuff. I also recommend most people learn to work with git from the command line. In my experience, GUI versions of git can often confuse new developers. Learning git at its core can help you work from any development experience.

[Mohsen Mirhoseini]

Nice job!
At last, what is your answer to the very famous philosophical question of "Shall we use Merge or Rebase?!" 😁

[Jason McCreary]

Absolutely. Some things are definitely easier with the GUI. Especially when visual. It's good to understand though how Git marks these conflicts though so you could do it manually.

[Karl Åström]

I would suggest you should never use --force, instead if you need that functionality use --force-with-lease which requires your remote tracking refs to be up to date

[Jason McCreary]

Good one. I'll read up more on that and maybe do a follow-up post.