6 ms·
Git commands you do need: git init git clone git add git rm git commit git push git pull git branch git checkout If you
by kramerger 4y ago
Git commands you do need:
git init
git clone
git add
git rm
git commit
git push
git pull
git branch
git checkout
If you use any others and you are a normal developer, chances are you are overcomplicating things and should rethink your way of using git.
But how about logs you may ask. Well, that's what we have tig for:
sudo apt install tig
cd repo
tig
- zirgs 4y agoYou forgot `git submodule`
- bombolo 4y agoNoooooooooooo!
- coffeeblack 4y agoThat’s the one part of git that I dislike.
- mst 4y agoI much prefer https://github.com/ingydotnet/git-subrepo https://github.com/ingydotnet/git-subrepo
- argulane 4y agogit-subrepo is a lot nicer to use than submodules.
- Forge36 4y agoThoughts on rebase?
- kramerger 4y agoMaybe, ... although these days rebase is mostly handled on the server. By the time your PR is reviewed its already behind main so server side needs to rebase it anyway before merge can be done. If you do rebase to squash commits, most projects prefer you didn't
- nicoburns 4y ago> If you do rebase to squash commits, most projects prefer you didn't I've been using rebase to fix bugs in earlier commits (on a feature brannch that hasn't yet been merged into main) so that you don't end up with broken commits in the history. I've also been using filter-branch to retroactively apply autoformatting to all commits in the branch.
- deleted 4y ago[deleted]
- xmcqdpt2 4y agoYou should rebase instead of merging when pulling though otherwise you contaminate your branch with merges that mess up the git log. Alternatively you can squash the merges before pushing but this still requires rebasing.
- searchableguy 4y agoI will add pull, fetch, prune, config, merge, remote, cherry-pick, reflog, rebase, reset, bisect, stash, etc to that.
- deleted 4y ago[deleted]
- throwaway525142 4y ago`git remote`?
- 0xCAP 4y agoSo basically no fetch, pull or rebase? Mmh...
- 5e92cb50239222b 4y ago… which results in either losing work sooner or later (because you don't commit often and early enough to always have something to roll back to), or pollutes history with junk WIP commits and merges. Maybe this is because I am not a "normal developer" (more like below normal), but this "overcomplication" both produces a clean and easy to read history (that is also easy to bisect when anything goes wrong and you need to find the offending commit), and also saved my bacon countless times.
- ilyt 4y ago> … which results in either losing work sooner or later (because you don't commit often and early enough to always have something to roll back to), You can just git add without commit. The changes will be saved to index and live till git decides to GC its files (so few months). Extracting those might be PITA (as requires playing with more arcane git commands) but you can't really lose data git stash is also lifesaver if you need to quickly jump to branch to do something else Lastly there is "git commit --amend" way of just incrementally changing the current commit but that requires some self-discipline (or hooks preventing your from) to not amend pushed commit and then having to fix that.
- Shacklz 4y ago> If you use any others and you are a normal developer, chances are you are overcomplicating things and should rethink your way of using git. I strongly disagree with this one. Git is one of those constants in our developer-live that is bound to stay for a long time. Probably longer than most other tech/tool that most of us use and learn on a daily basis. The fundamentals of git aren't that complicated, the datamodel isn't any more complex than what you get taught in an introductory datastructure course. And once you understood it, you can leverage it to create an actually readable and usable commit history instead of the unreadable mess that your average enterprise project is. In my opinion, it's well-worth the trouble of taking an afternoon to understand git beyond the commands you've mentioned.
- kramerger 4y ago> The fundamentals of git aren't that complicated, Agreed > the datamodel isn't any more complex than what you get taught in an introductory datastructure course. Also true. The problem is that people love to shoot themselves in the foot by overcomplicating normal use of git That's all fine, until you try to push to someone else's repo and things start to crack. So as a person who had to maintain a fairly large project, and had to fix a lot of madness from developers I nowadays suggest everyone keep their git adventures to a minimum.
- ilyt 4y agono git stash ?
- forgotpwd16 4y agoThe `git stash` is useful but that by default status doesn't show anything related to stashed changes makes it easy to forget you have them. Can replace stash workflow with commit, branch, etc and have one less thing to think about.
- ilyt 4y agoI mean I can configure my shell correctly so that isn't a problem in the first place -> ᛯ date >> asd [23:57:10] ^ [/tmp/a] {master *} -> ᛯ git stash Saved working directory and index state WIP on master: bf5a0f8 fix [23:57:13] ^ [/tmp/a] {master $} -> ᛯ git pop On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: asd no changes added to commit (use "git add" and/or "git commit -a") Dropped refs/stash@{0} (4f46bc00a3d6032c2726f04540a44656090e05ca) [23:57:16] ^ [/tmp/a] {master *} -> ᛯ it's pretty non-missable (git pop is just alias to stash pop)
- RichardCA 4y agoIf your work-in-progress files are trivial, it's easy to create a temp directory with a .gitignore with just a '*' in it and leave your files there. If it's not so trivial, create a local temp branch so you can cherry-pick it or merge it back in later, or maybe convert your temp branch into a more enduring one. Stashes are pseudo-commits with no branch context, and are more of a conceptual burden then they're worth.
- ilyt 4y agoor just type git stash do whatever you need git stash pop done > Stashes are pseudo-commits with no branch context, and are more of a conceptual burden then they're worth. They are literally just commits like everything else. They just land in refs/stash, where branches/tags live. Man the shit people say about how git works while not knowing how git works... It's essentially a temporary branch with some syntactic sugar to manage You can even just convert it to normal branch git branch cake stash@{0}
- bombolo 4y ago> If you use any others and you are a normal developer, chances are you are overcomplicating things and should rethink your way of using git. Or perhaps I bothered to read the documentation and I know more than you.
- ilyt 4y agoFrom my experience the circles of "complains about git" and "read the manual properly" barely touch But that list of commands isn't really far off for daily/weekly use, I'd only use stash and rebase over that most of the time
- coldpie 4y ago> om my experience the circles of "complains about git" and "read the manual properly" barely touch Yuuup. For anyone reading this who thinks of Git as a bunch of magic commands, go read all of gittutorial, gittutorial-2 and gitcore-tutorial. That last one is particularly important to read & follow along with. It gives you Git's underlying data model, which makes it much easier to reason about what the UI-level commands are doing. I even used that knowledge once to recover my boss's lost data at a previous job! He had git-added a new file, and then lost it (git-clean/git-reset/something) before committing. I knew from reading that tutorial that git-add is sufficient to add it to git's object store, so we managed to find the right object using file timestamps and git-cat-file to retrieve it. https://git-scm.com/docs/gittutorial https://git-scm.com/docs/gittutorial https://git-scm.com/docs/gittutorial-2 https://git-scm.com/docs/gittutorial-2 https://git-scm.com/docs/gitcore-tutorial https://git-scm.com/docs/gitcore-tutorial
- deleted 4y ago[deleted]
- nicoburns 4y agoYou're missing: git status git log git reflog git reset git merge git cherry-pick git rebase These days you can use the new (and less confusing) "git switch" and "git restore" commands instead of "git checkout". I still use "checkout" because it's ingrained in my muscle memory. But I wouldn't recommend it for new developers.
- forgotpwd16 4y agoWorth noting that `git switch` and `git restore` have been introduced (few years now) as easier-to-use alternatives to `git checkout`. Even in status you can see it's restore that is shown in the help messages. From commands mentioned, it's missing (one of) my most often used one(s) `git diff`. What's the point of using a version control if to never check what changes are made?
- marssaxman 4y agoI recently retrained myself to use 'switch' and 'restore', and a perceptible fraction of my lingering loathing for git's incoherent UI has now faded.
- xmcqdpt2 4y agoYou are missing some of the best, most useful git commands: git diff git log git blame git bisect A major advantage of version control is being able to navigate history.
- u801e 4y agoOne command I use that I haven't seen anyone mention so far is git apply. I use this to stage or edit diff hunks before committing. Basically, at least in vim, I can highlight part of the diff (along with the diff header) and pipe it to the git apply command with the --cached and --recount flags to stage or unstage changes. This, at least in my opinion, is easier to use than the -p flag for git add or git reset, and provides much finer grained control over staging and unstaging compared to those commands.
- mariusor 4y agoI think the main usefulness of tig lies with it's interactive staging screen. It's basically the TUI version of git add -i.
- mbork_pl 4y agoWho needs `git pull`? It's just a footgun.