5 ms·
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 A
by panpanna 7y 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 7y agoI'd add stash and log.
- SamBam 7y agoI 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 7y agoHow 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.)
- dspillett 7y 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.
- dwhitney 7y agoI've had engineers tap me on the shoulder with a proud look on their face while pointing at some crazy mess of branches they've just spent hours futzing with to finally get "right". It would have taken them a fraction of the time to just fix whatever issue they were having by following the advice above. People really take git histories WAY too seriously.
- dspillett 7y agoI can see the point of being pathologically protective of your own source history. But the project you are sending a PR to only really need to see the final effect of the changes. Of course for your own local history the same technique can work, you just keep the old branch as well as the newly cleaned one. Though that might be unnecessary clutter to many.
- deleted 7y ago[deleted]
- simiones 7y agoYou 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.
- dahart 7y agoGit 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.
- panpanna 7y agoI prefer using "tig" for browsing the commit log. "git log" is just not usable in real world. Stash is something I try to avoid after multiple accidents.
- dahart 7y agoFull disclosure, I have a wrapper script to make git log output a lot more readable for me, it columnizes and shortens and colors the output. I’d agree the defaults are not amazing, and even with log’s many arcane options it’s very difficult to make it feel smooth.
- dwhitney 7y agoheh, I'd take tag out of there and let CI handle that. Good list though.
- panpanna 7y agoThe 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.
- darepublic 7y agowhy don't you like git diff. git diff --cached in particular is nice to review your staged changes prior to commit.
- flickster 7y agoInstead of git checkout I would definitely recommend git switch/restore when using a current git version as they feel much more natural.
- mFixman 7y agoDon't forget `git cherry-pick`! IMO that's the most underrated git command.
- LanceH 7y agoThis is the single time I prefer to use a gui client so I can get visual confirmation of what's coming in.
- rsync 7y 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 7y agoI love command lines, but if you are reducing this to a minimum you can replace the top line with git gui