99% of the Git commands you'll need at work, demonstrated in a single script

https://bitbucket.org/BitPusher16/dotfiles/raw/49a01d929dcaebcca68bbb1859b4ac1aea93b073/refs/git/git_examples.sh

by carodgers • 7 years ago

659 154 7 years ago

carodgers3• 7 years ago

I got a little tired of running to Google every time I needed a non-trivial git command, so I set out to identify all (and only) the git commands I require for my day-to-day and capture them in one place. The result is this script. It can be run fully on your local machine, no remote accounts required. (But it still shows how to use remote repos!)

I'd also be interested to hear what git commands others use frequently (that don't involve a GUI). I'm curious to know which workloads might require some of git's more advanced features on a regular basis.

adrianN2• 7 years ago

I use git log -S regularly

https://www.git-scm.com/docs/git-log#Documentation/git-log.t...

katet• 7 years ago

A couple of random addendums (although these aren't necessarily what you'd use day to day)

git diff --color-moved

(seriously, read through the man page for git diff sometime)

git log -p --all -- <path/to/file>

(I use this with multiple remotes, so I can track changes in my fork and in upstream when looking for context around a file)

git cherry-pick -x

(for automatically adding a reference to the original commit)

A couple more, but I think they're really quite specific to my personal workflow and responsibilities

carodgers3• 7 years ago

git log -p --all -- <path/to/file>

I like this one. I'll remember it. Thanks for sharing!

Myrmornis2• 7 years ago

(shameless plug): https://github.com/dandavison/delta is a syntax-highlighting pager for git that adds syntax highlighting and within-line edit detection to all diffs displayed by git.

I agree about `git log -p`. A good trick with that is to use it as a quick way to search for a commit that includes a certain string (since the pager is less, one can search back in time with `/`).

Same trick for `git reflog -p`.

`git stash show -p` is another less-known diff command (look at a stash without applying it).

coldpie5• 7 years ago

I got a little tired of running to Google every time I needed a non-trivial git command

Have you read through the gittutorial, gittutorial-2, and especially the gitcore-tutorial manpages[1]? Reading those guides and actually following the steps and examining the results on disk was extremely helpful for me in understanding how Git actually works. Once you've got that understanding, the Git UI seems less arbitrary. You can start to see how it was put together over the years, which should help you use the tool more intuitively and effectively.

I'm curious to know which workloads might require some of git's more advanced features on a regular basis.

I work on a very large and very old (mid-90s) project, so history-diving and diffing branches is very useful for me. I use all of git-blame, git-show, and git-diff to examine history to learn how the code came to be as it is. Even git-cat-file comes up occasionally when I just want to look at some old object I happen to have a hash for and don't want to look up properly through the porcelain.

We also maintain a bunch of branches and backport modern commits onto legacy branches. git-rebase can help for this, but more often I find myself doing it manually (well, with a bash script) with git-cherry-pick, as it's easier to work with commits without being in the middle of a rebase operation. Knowing git-log's many options to massage history into a useful form for my work comes in very handy here, too.

More details on the rebasing procedure I use: https://github.com/ValveSoftware/Proton/blob/proton_4.11/doc...

Here's some of the tooling I use often. For Git stuff, see pick_commits and gitconfig https://gitlab.com/mywinetools/mywinetools/

[1] I know, I know, no one likes studying and learning how to use a tool. But sometimes you gotta if you want to use the tool effectively.

taneq• 7 years ago

How much required reading should a version control tool really need before you can use it competently?

carodgers3• 7 years ago

gittutorial I had seen before, but the others I had not. Thanks for that, I'll give them a go.

Wow, mid 90s! Git came out in 2005, so I assume they started out using some previous version control and then switched to git? That must lead to some serious knots. Is there a way to retroactively migrate source control history into git? Depends on the legacy source control tool, I guess.

I think git-blame and git-cat-file are probably the next commands I need to explore in depth. Will investigate those further.

Thanks for sharing your gitconfig as well. Always interesting to see how others are streamlining their workday.

panpanna3• 7 years ago

I feel the list of useful for commands should be much shorter:

    git add/rm/commit/status/push
    git branch/checkout/merge/rebase
    git tag/push --tag

Anything else should be handled by policies. If you get bad PR, reject it instead of trying to fix it using some complex sequence of git commands.

edflsafoiewq• 7 years ago

I'd add stash and log.

SamBam• 7 years ago

I personally find `cherrypick` to be occasionally helpful, as a way to jump out of trying to be too git-clever, and simply starting a new branch and pulling in the useful parts of another branch.

That's probably anathema to some users, though.

wwright• 7 years ago

How is the PR author supposed to fix it without complex Git commands? Error prone copy and paste?

I _really_ love working with Git, but in my experience engineers unfortunately do need to tap into the long tail of “advanced” commands fairly often. At least often enough that they will quickly be frustrated by it.

(I’m currently helping move a bunch of our engineers from SVN to Git, and while I believe the better ecosystem will be worth it, it does break my heart every time someone has pointless trouble simply because of Git’s CLI.)

dspillett2• 7 years ago

How is the PR author supposed to fix it without complex Git commands? Error prone copy and paste?

Reclone from master (or the active branch if something else) to another directory, merge in their final changes, manually if needed, properly test the result, and sent a new PR with the cleaned up version?

(caveat: I've not used git in anger, there may be more to it than that, but I can't imagine much more)

I suppose who is responsible for dealing with cleaning up updates before merging them into the main project depends upon who wants it merged most: the PR submitter because they want a fix/change/other in upstream so they don't have to maintain their own fork, or the project maintainer because the update is more generally useful to other users or more specifically useful to the maintainer.

If you submit a badly arranged PR or other patch you are creating extra work for the project maintainer(s). Depending on the project and maintainer(s) this may be acceptable or, equally rightly, it may not.

simiones• 7 years ago

You need to add `git stash` to move to a different branch while having changes wide open.

You also need `git log` with all sorts of arcane options if you actually want to use the history.

dahart4• 7 years ago

Git log is probably the single git command I use most often.

Stash can be useful, but it’s good to know that you can get by without it very easily, there’s nothing you can do with stash that you can’t do with commits & branches, and stash doesn’t have the same safety mechanisms that commits have. I think the biggest git accidents I’ve seen, where people have gotten confused in the middle of a merge and lost their work, are due to using stash.

ufo• 7 years ago

Viewing the git history is one of the handful of things where I prefer a GUI (gitg) instead of the git command line.

commandersaki• 7 years ago

Since using `git worktree` I never use stash.

collinmanderson• 7 years ago

yes, `git stash` is incredible useful. Also needed for `git pull --rebase` when there are uncommitted changes.

dwhitney2• 7 years ago

heh, I'd take tag out of there and let CI handle that. Good list though.

panpanna3• 7 years ago

The thing is, some CI operations can be triggered by existence of tags.

For example build and test all commits but deploy only if it's on master branch AND has a version tag.

darepublic2• 7 years ago

why don't you like git diff. git diff --cached in particular is nice to review your staged changes prior to commit.

flickster• 7 years ago

Instead of git checkout I would definitely recommend git switch/restore when using a current git version as they feel much more natural.

mFixman• 7 years ago

Don't forget `git cherry-pick`! IMO that's the most underrated git command.

LanceH• 7 years ago

This is the single time I prefer to use a gui client so I can get visual confirmation of what's coming in.

rsync• 7 years ago

"I feel the list of useful for commands should be much shorter ..."

My own list contains:

  ssh user@rsync.net "git clone git://github.com/LabAdvComp/UDR.git github/udr"

... which is how I make my own copy (in the cloud) of (what I consider to be) important packages that I want my own archive of.

elsjaako• 7 years ago

I love command lines, but if you are reducing this to a minimum you can replace the top line with

    git gui

HocusLocus• 7 years ago

Ran this script, it uploaded my whole network to Github as an open source project and sent a broadcast notification to Krebs On Security.

hnhg• 7 years ago

Is that what you wanted?

aequitas• 7 years ago

Try Gitless[0]. It's an alternative 'UI' to Git which is kind of build top down instead of bottom up. The commands are much higher in the abstraction tree and clear single operations and dropping some concepts like the staging area. It operates on the Git database the same way 'normal' Git does so you can always fall back.

[0] https://gitless.com/

sidpatil2• 7 years ago

It's an alternative 'UI' to Git

Also known as a porcelain, as opposed to the low-level commands known as the plumbing.

etbebl• 7 years ago

My understanding is that in git-land, "porcelain" and "plumbing" usually refer to a specific dichotomy of high-level vs. low-level git commands, rather than further abstractions over the commands such as a GUI.

Munksgaard• 7 years ago

I know this has been mentioned a million times on here, but for the off chance that someone hasn't heard about it before I'm going to completely disregard that and say that Magit for Emacs is an incredibly helpful tool for interfacing with git repositories that I couldn't imagine working without it. It's by far the best interface to a version control system that I've ever used. It has helped me understand how git works behind the scenes, and allows me to effortlessly work with branching, stashes, merging, rebasing, remotes and much more, without remembering a bunch of arcane git commands.

hwj• 7 years ago

Magit sounds great. If I only could use it without remembering a bunch of arcane emacs commands.

shpx• 7 years ago

If you've memorized the arcane vim commands, try Spacemacs or Doom Emacs.

http://spacemacs.org/

https://github.com/hlissner/doom-emacs

In magit in those Emacs distributions, the question mark brings up a list of available commands and if you type the first letter of a command with multiple letters, it'll show you the names of the actions that start with that key.

phalangion• 7 years ago

Spacemacs makes emacs commands both less arcane and more discoverable. Give it a shot.

weaksauce• 7 years ago

use spacemacs and it's much more accessible. magit is phenomenal software and it's both a blessing and a curse that it's tied to emacs... it probably wouldn't exist as easily outside of emacs and it's a small pain to use for people that don't use emacs already.

motform• 7 years ago

One of the things that make magic so great is precisely that one does not have to remember all the shortcuts. The author has written and released his own tool for popups and tooltips[0]. The keys are also among the more sane binds you find in Emacsland, so you can often browse by guestimation.

[0] https://emacsair.me/2019/02/14/transient-0.1/

_verandaguy• 7 years ago

For those among us of the Vim-family persuasion, there's tpope's ever-popular vim-fugitive[0], with such handy commands as `Gcommit`, `Gadd`, and one of my personal favourites, colour-coded `Gblame`.

  [0] https://github.com/tpope/vim-fugitive

yodsanklai• 7 years ago

I find myself more productive on the command line. It just feels "safer", esp. for anything that changes state. And I always prefer not using the trackpad if I can avoid too.

I know without hesitation all commands I use daily. And then I keep a note with the few commands I use less often. An exception is when I want to display changes between version, or conflict resolution.

That being said, I'd like to rely just on my IDE (VSCode) for better consistency, and I tried a few times, but I always return to the command line which is a great tool. For the same reason, I prefer to `CMD-tab` to terminal and `make` rather than build from the IDE.

gpderetta2• 7 years ago

And I always prefer not using the trackpad if I can avoid too.

this is emacs we are talking about :) you are supposed to use the keyboard for everything.

sidpatil2• 7 years ago

I really enjoy using Magit, since it makes partial commits a breeze. Unfortunately, it's notoriously slow on Windows, so I ended up migrating to Git's interactive-mode commit utility.

gpderetta2• 7 years ago

well, it is not exactly amazingly fast on Linux either, to be honest.

rgrau• 7 years ago

I'm in deep love with magit, but in my case it has done nothing to know more about the git internals but the contrary.

In which cases you found it "opens" git for deeper inspection?

My experience is that it lets me operate at higher levels of abstraction than cli git. (e.g. Instant Fixup)

StreakyCobra• 7 years ago

Without Spacemacs having me brought to the Emacs worlds, I would have never discovered magit. Nowadays I am soo tied to it that I even have a `magit` script that can be called from anywhere:

  #!/usr/bin/env bash

  emacsclient -c --eval "(progn (magit-status) (delete-other-windows))"

The learning curve is a bit long, but really worth it!

Note: this require you to have setup emacs as a deamon somehow

ChanderG• 7 years ago

Sharing my personal experience to add to this.

I was happy with the git cli (and occasional tig) when I started using magit full time and initially never understood all the buzz. It did not seem that powerful over what I was using.

After 3-6 months of use, for some reason I had to go back to the cli and then I realized the ease and speed I had got accustomed to.

Magit is magical; use it for some time and try going back to your previous setup.

busrf• 7 years ago

I recently started using Magit, and one of the first things I did was cruising through a gnarly interactive rebase full of fixup commits with it. It was amazing.

One of the things I appreciate about magit is that it gives you sane default behaviour. For instance, the -f option when pushing with magit is —force-with-lease, rather than —force, so that you don’t inadvertently overwrite someone else’s work. When stashing, it helpfully prompts by default you to enter a message for your stash to differentiate it from the 10 other stashes you might have on a branch. Sure, these are things you can get on the command line, but they’re not the defaults, and you have to remember how to get to them.

I only have emacs open for magit (:

psv1• 7 years ago

Can anyone point to a good guide and/or tool for resolving merge conflicts?

Asooka• 7 years ago

The ones listed as options for git mergetool are all good. Personally I use kdiff3, it has a simple interface for choosing conflict resolutions and can often resolve some of them on its own.

adrianN2• 7 years ago

I liked this http://vimcasts.org/episodes/fugitive-vim-resolving-merge-co...

coldpie5• 7 years ago

Set merge.conflictstyle=diff3!!!! The default merge style is utterly useless, I have no idea why it is the default. diff3 gives you three pieces of information: the status before at the common ancestor; the status on the current branch; and the status on the to-be-merged branch. You can then understand what changes were made on each branch, and decide how to merge them intelligently. Without that common ancestor, it's way way harder to understand what you're looking at.

dahart4• 7 years ago

I’m a fan of using Perforce merge (p4merge) with git. It’s free to download and use, and easy to integrate with git. I remember thinking the UI was weird the first time I used it, but since then I’ve tried a bunch of merge tools and haven’t found something I like more. It shows common ancestor by default, and lets you hand-edit the merge section, which not all merge tools do.

darepublic2• 7 years ago

many modern IDEs will help with this, ie. visual studio code. It will highlight and name the conflicting code by branch.

When the conflict occurs you can do git status and the highlighted files are those with a conflict -- at that point you can just navigate there in the code editor of your choice and look for the <<<< blocks. After you get those files into the state you would like then you run 'git commit' to resolve.

sixstringtheory4• 7 years ago

I have used Kaleidoscope [0] for a few years now to resolve merge conflicts, it's a powerful and beautiful app, and the key bindings are great to fly through conflicts and select "mine", "theirs", "mine-then-theirs" or "theirs-then-mine". And you can also hand edit the resolved version. It's also great for git diffs and file/dir diffing, and can be summoned from the command line with `ksdiff`.

[0] https://www.kaleidoscopeapp.com

vfc1• 7 years ago

Thanks for sharing, but I feel like it's more like 99.999%. The essential commands for development are really a lot less than this. Maybe it's a list for release managers / sys admins?

Committing, pushing, handling local branches, updating, merging, rebasing, cherry-picking, squashing and stashing is almost all that everyone uses, and several of those not even on a daily basis.

stunt• 7 years ago

Developers having hard time to master GIT after so many years is just a good argument to "Why we need GO more than Scala" and a very disappointing reality at the same time.

JamesQuigley3• 7 years ago

I'm personally a huge fan of https://www.gitkraken.com/ (I also used to work there.) Don't have to memorize git cli commands and get beautiful visuals on top of that.

rinchik• 7 years ago

ugh i hate GUIs, for me those are a middle man. With cli, i can "feel" git. with GUI i'm just telling a 3rd party to talk with git for me. That 3rd party can also screw up some communication, just like in telephone game.

wruza• 7 years ago

They also fail to at least show you the conversation before it starts, so you could align your ideas on what can go wrong. I had to ditch tortoise<vcsname> for this exact reason in our entire division, except for simple initial checkouts. That damn thing always tried to append some “--qwerty --asdf” to every innocent command it could be asked to perform.

jackcodes• 7 years ago

I do appreciate that this is probably a cracking tool for beginners and juniors. If it was skilling someone up to git using this tool or not at all, damn right I’m choosing this.

But I can’t bring myself to run a web browser to run git commands either. The git binary on my system comes out at 2.5Mb and the MacOS .app bundle for this is 346.5Mb.

JamesQuigley3• 7 years ago

Yeah pretty much every app I run nowadays is Electron. Don't love that, but they bring me enough value that it's 100% worth it for me. I'm with the other commenters that I don't like having to google a git command every time I have to do something more complex than add/commit. GK is perfect in that sense

mroche• 7 years ago

It’s been a long span of time since I’ve used GitKraken or Atlassian Sourcetree, but GK had some serious performance issues with larger repos in my experience. Very clean app, though, and I did enjoy it.

Right now, Im partial to Sublime Merge[0] as it’s fast, has a clean UI for diffing, shares many similarities with Sublime, and also shows the use what git commands they’re running by hovering. It can be a very effective tool for learning git. It has the same evaluation structure as Sublime, so that’s a bonus as well.

[0] https://www.sublimemerge.com/

JamesQuigley3• 7 years ago

Yeah there definitely used to be some perf issues. There have been some massive improvements recently though for big repos. You should give it a try again!

BalinKing• 7 years ago

Hi, James (it's Josh Grosso)! Are you not at Axosoft anymore? If not, where'd you move to (and how are you doing either way)?

pastrami_panda• 7 years ago

'git add -i' is my new favorite. When you want to stage certain files but don't want to type out the paths over and over again to deeply nested files

niark• 7 years ago

After years of wanderings, I've settled with Fork which is a a delightful GUI. Polished, feature-rich, and still improving on a regular basis. Kudos to the authors!

[0] https://git-fork.com/

therealdrag0• 7 years ago

I switched from SourceTree a few months ago after seeing Fork on HN. I couldn't be happier with it!

Love seeing high-quality software developed by just 2 people.

sixstringtheory4• 7 years ago

Same, I spend about 50% of my time in git on the command line, the other 50% in Fork. I've used SourceTree -> Tower -> Fork and I'm very happy with where I'm at now.

liquidify2• 7 years ago

hmm why no linux?

johncoltrane• 7 years ago

He is a MacOS developer (Swift, Cocoa), she is a Windows developer (.NET, WPF).

jeena• 7 years ago

The example commit messages are triggering me.

thrower123• 7 years ago

This kind of thing is why I'm very glad that the Team Explorer git plugin in Visual Studio has become decent enough that I don't have to drop into the cmd line, pretty much ever.

anreekoh• 7 years ago

If you want git on the command-line, but don’t want to remember commands, try lazygit[0], it’s changed what I’m comfortable doing with git because it can tell me at any given moment what I can do.

[0] https://github.com/jesseduffield/lazygit

trevor-e3• 7 years ago

Maybe my workflow is a lot easier than others, but I work on a team of 10+ engineers and my Git usage is dead simple. I do everything from a GUI (Fork for macOS) and very rarely have to deal with any complicated issues that require a terminal.

- Always pull w/ rebase for the current branch.

- Always merge other branches into your current branch, eg master -> feature.

- Always stage individual chunks of code one at a time to make sure I'm committing the right stuff.

- Always squash feature branches into a single commit when merging back.

- Stash changes if needed when switching branches.

- Cherry-pick one-off commits if needed.

- Append a previous commit that I haven't pushed yet if I happened to forget something.

- For complicated merge conflicts I switch to Visual Studio Code which also has a great GUI.

I think this covers 99% of the stuff I encounter in my day-to-day.

ssully• 7 years ago

I am in a similar boat, except I just Githubs desktop client. In the past 4 years, I think I have had to use the command line under 10 times.

doubleunplussed2• 7 years ago

Am I missing something, or is it impossible to, y'know, check out a previous revision using github desktop? Create a branch at a previous revision? Reset the branch to some previous commit? Any of these things?

It seems to have next to zero functionality. What is the point of it? What you you use it for, other than commit, push?

5trokerac3• 7 years ago

In my experience, if you ever use more than clone, fetch, pull, push, checkout, merge(tool), reset, add, and commit then somebody messed up.

CameronNemo• 7 years ago

I rebase all the time FWIW.

marcosdumay• 7 years ago

Nearly every time that I google a git command, it's something related to tags.

danpalmer• 7 years ago

I agree. Almost every time I hear of someone having issues unpicking a complicated git issue it's because they were trying to be too smart with it and use every feature just because they are there.

Find a _simple_ git workflow, document it in a style guide, stick to it. Git doesn't have to be complicated.

whycombagator• 7 years ago

kdiff3 for merge conflicts is nice (I think)

arcticbull• 7 years ago

I agree with basically everything you wrote except I’ve had much better experience rebasing my feature onto origin/master instead of merging master into feature. Keeps the [branch] history cleaner.

dmlittle• 7 years ago

Same thing here. If I'm working on a feature that I haven't pushed up yet I might squash my commits together for a cleaner history (it also helps with rebasing). If you ever mess up a rebase and finish it before you're able to abort you can use `git reflog` to get a reference back to the previous commit. It's come super handy a few times.

trevor-e3• 7 years ago

I think what I said should be equivalent to what you do. When I merge my feature back to origin/master I do `git merge --squash myFeatureBranch` which automatically rebases everything and keeps a clean history.

This is really the only command I do by hand because I can't find the equivalent (yet, probably haven't looked hard enough) in Fork.

edit: oh I think I misread what you said. When working on a feature branch I don't care too much about the branch history since I know it's eventually being squashed back into a single commit.

johnisgood4• 7 years ago

I hate merges. "Merged ... into ..." is such an uninformative message! Some codebases are filled with those. I prefer seeing each individual commit messages, so... rebasing all the way for me! One problem I have with this is that the committer date of all commits become identical instead of retaining their original date aligned with the author date (which I would like to be the committer date). Is there a way to workaround this or fix it in a "non-dirty" way? It might be the case that I am doing something wrong, if so, what am I doing wrong exactly, or how should I go about it?

pjmlp• 7 years ago

Same here but from Visual Studio, Eclipse and Tortoise GIT, while missing Subversion and Mercurial.

mav3rick• 7 years ago

I will never understand why people use a UI for git. 99% of the time people who do that don't understand how git works. When something deviates from the normal workflow they struggle.

SQueeeeeL• 7 years ago

Never understand? I mostly use Git CLI, and it's a big pain. Weird terminology, needing to memorize branch names for easy use, differences between staged and pushed commits. And when you mess your incantation you ripped from SO up you get errors with strange terminology. I understand it's benefits and use it, but older simpler versioning systems like SVN had their own benefits.

dmix• 7 years ago

It's only an alternative interface... not much different pushing a button you don't understand than copy/pasting some commands.

trevor-e3• 7 years ago

I think that's just your own personal bias on the matter – 99%, really? To me (IMO), Git is something that's inherently visual and not really suited to a CLI, it has nothing to do with not understanding how Git works under the hood.

iaml• 7 years ago

I use git UI because I want to have a good graphical overview of the repository. Really helpful on larger repos.

Mirioron• 7 years ago

And if they didn't use a GUI they either wouldn't use git at all or they would struggle with that too.

petepete2• 7 years ago

To be honest, staging individual hunks without a UI is a pain. I use Tig (a TUI) just for this.

saagarjha• 7 years ago

Git is well suited to graphical interfaces, since it's quite useful to visualize the commit graph and for viewing diffs. The fact that the git command line tool is quite awful makes this even more of a no-brainer.

40four• 7 years ago

I get what you're saying, but not that they necessarily don't understand git. I guess it's just personal preference.

I don't know why, but I've always felt uncomfortable using git in a GUI, but I know a lot of people who love it.

For some reason, anytime I try to use a GUI, I don't feel like I'm really doing git, if that makes any sense. Also, I've personally never felt the need to see the branches visually. And if I do get the itch to 'see' them, nothing a quick

    git log --oneline --graph

cant fix!

gregmac• 7 years ago

Totally agree with everything on this list, with two exceptions:

* I almost always just do a regular merge to master (rather than squash).

* I use GitKraken which (in the pro version) has a great merge tool.

A lot of people seem to want "clean history" so just I'd just like to put it out there that it's not really necessary (there's nothing wrong with it, of course), and regular merges work just fine. In my experience, the two main reasons I look at git history are:

(1) Checking when a feature was done and what releases it got into

(2) Finding out why a particular line of code exists (blame)

For (1), with software with numbered releases, you end up following the branches anyway. Having the individual commits from feature branches makes you scroll more, but it doesn't make it any harder to follow. If you really don't like seeing them, you can hide anything but merge commits.

Even simpler, if all you care about is whether a given feature branch is done (merged) or not, that's easy to see and the same as a squash-merge workflow.

With continuously-deployed ("cloud") services, things are even simpler - you start at the hash currently deployed and go backwards. It makes no difference if there's one branch or many feature branches (other than scrolling past more granularity).

For (2), the greater granularity from individual commits is generally useful (at least provided that each commit has a ticket number and useful description), and squashing erases this detail.

Also, a nice thing is if you end up merging the same branch to multiple places (master and a release branch, for example) it's obvious what happened by looking at the tree. Contrast to if you cherry pick a squash merge commit, the only way to see that is to read both commits and realize they're the same -- and this is much less obvious if there's other commits between them.

Basically, squash merging doesn't help with either of these, and in fact actively hinders (2).

My team has been doing this for a few years, and I'm not even sure if it was a conscious decision to merge this way (or not do squash merge) but we've had no reason to change. It does depend on every commit being well-formed, but this is pretty easy to ensure in a paid team that works on this every day (whereas with open source I'm not sure it'd work well).

Anyway, like many things in git, there's more than one way to do it, and there's no clear "right" or "wrong" way.

Groxx• 7 years ago

This likely works because a) you know what you're doing (cherry-pick), and b) you're being careful (staging carefully).

Anything works when both of those prerequisites are met. You're unlikely to do the bad things that force more advanced needs.

Everyone should do this. Think back to how much time you've lost due to git problems. It'd probably take less time to learn it correctly up-front, and never have to deal with them ever again.

wilg• 7 years ago

I am similar but avoid rebasing entirely in favor of squashing. Squashing can also be used to turn a messy branch into a new branch full of nice clean independent commits.

I also don't bother appending (though my GUI lets me undo the last commit if I haven't pushed which is maybe the same thing.)

Most developers get way too fancy with Git and screw something up. I use GitHub Desktop and rarely touch the command line for Git. It has a great UI for being able to just pop over and see my current changes, and easily commit just a line or two from them to make commits other people can understand.

qmmmur• 7 years ago

Why do you always rebase? Is your master essentially the stable branch of the program you are collaborating on?

lbenes• 7 years ago

When I want to get back to a pristine state, I prefer

$ git reset --hard origin/master

over the suggested

$ git reset --hard HEAD

If you use git and don't know the difference, read this: https://stackoverflow.com/questions/8196544/what-are-the-git...

karmakaze• 7 years ago

git reflog # for those times you get lost and want to go back

shaneos• 7 years ago

I took all my most common Git commands and made them far easier to type - here's the script in case it's helpful to you https://github.com/shaneosullivan/git-shortcuts

RealityVoid• 7 years ago

I just found out today about git worktree[1], and I think it's a very powerful feature more people should know about, but it seems used less than it could.

Basically, you can do a working copy of the git environment without pulling the repo again, so you have only one .git folder.

A godsend if you, like me, work on gigantic repos that build unbearably slowly and want to be able to use multiple instances of the same repo at the same time.

[1] https://git-scm.com/docs/git-worktree

jomar• 7 years ago

Compared to the previous technique of creating a new separate local clone for unrelated simultaneous work on a project, it's also glorious when it comes time to clean up and delete no-longer-needed extra working directories.

After `make clean` and `git status --ignored` shows nothing worth preserving, you can delete the worktree (via `git worktree remove`) with impunity. No more paranoid checking that there is no valuable work stashed or hiding in other branches before typing `rm -rf`, as those are shared with the main worktree so won't be lost.

jnurmine3• 7 years ago

Silly little alias, "git top".

  [alias]
          # top 10
          top = !sh -c 'git log --oneline|head -10'

It shows the top 10 commits. I use it several times every day, to orient myself while flipping between multiple repositories and branches.

mhd• 7 years ago

Isn't that just 'git log --oneline -10'?

jnurmine3• 7 years ago

Indeed, thanks. I've had the alias for years and never thought to optimize it.

dankohn1• 7 years ago

Try going a little fancier:

  alias hist='git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short'

jnurmine3• 7 years ago

Nice! Thanks.

ShteiLoups• 7 years ago

I used to live and die by the command line.

Then I met sublime-merge. And fell in love. It is the only Gui I find more efficient and beautiful than my terminal. I highly reccomend it.

B1FF_PSUVM• 7 years ago

#CodeSmell

(i.e. that this is necessary speaks volumes)

darnir• 7 years ago

Awesome! Now show me how this is done in Mercurial

wyclif• 7 years ago

One tip I give people who feel overwhelmed by Git is that unless you are an edge case, you can probably do most of what you need to get done with these six commands:

branch checkout add commit pull push

Reading and understanding the documentation for those six core commands isn't a big investment, and it will pay off if you're doing software or documentation development.

KuhlMensch• 7 years ago

I'd say I literally use pickaxe (-S) and the -G one a few times a week. Often to answer questions I hear around the office. If you are not familiar with it, I think its an amazing. Err... I guess...check it:

http://www.philandstuff.com/2014/02/09/git-pickaxe.html

Also I do allot of

git reset --soft HEAD;

(pick-hunks-with-GUI);

git stash -u -k;

run-test.sh;

git commit -m "blah"`

hansdieter1337• 7 years ago

"UNEXP_CONT=$(ls sandbox/..." this will ignore hidden files. So does the "rm -rf"

99% of the Git commands you'll need at work, demonstrated in a single script

Related Stories