答えられる42のGit質問

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.

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.

stage is a built-in alias for add.

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.

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

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

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.

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.

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.

It's a separate command and available as an npm package.

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.

git branch -m current-branch-name new-branch-name

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

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

I cover configuring and customizing your terminal in Getting Git.

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.

Yes!

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

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

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

Awesome. Send them .