5 ms·
I cannot be the only one that gets away with only knowing: git pull git merge x git checkout [-b] foo git commit git push
by adaboese 3y ago
I cannot be the only one that gets away with only knowing:
git pull
git merge x
git checkout [-b] foo
git commit
git push
- baggy_trough 3y agoYes, this is very good. Also, rebasing is evil.
- gear54rus 3y agoBecause your IDE shows line-based blame and allows to check out old file versions via right-click? :) Mee too
- deleted 3y ago[deleted]
- mixedmath 3y agoPossibly `git branch NEWBRANCHNAME` instead of `git checkout -b NEWBRANCHNAME`. When I need to show git to someone in order for them to contribute to something, I give them only these incantations --- and instructions to ask me if weird git things happen.
- rkangel 3y agoYou then need to do both `git branch xxx` and `git checkout xxx` though. If you teach "checkout to move around and add -b when moving to a new branch the first time" that works pretty well
- still_grokking 3y agoIt's `git switch [-c]` nowadays.
- someone7x 3y agoI've given up trying to configure git push the branch I'm on so I type this little dance each time : git switch -c foo git push > did you mean git push --args-with-branch-name? sigh, copy, paste, enter
- bravetraveler 3y agoI manage with even less, any merging under my watch happens as a strategy with pulling
- _ZeD_ 3y agoFWIW that's 99% of my usage of git (well... it's about 1% because I do everything using the eclipse git UI, but that's the same behavior you get from that commands)
- have_faith 3y agoI know a decent amount of git, but day to day I use GUIs (Sublime Merge).
- ryanjshaw 3y agoThe most important command: git reset --hard
- kreeben 3y agoThis is my favorite. It allows one to easily create "service" branches based on tags where you apply to that tag a select set of commits from the development branch that you can then easily deploy to PROD without including the rest of the (perhaps not sufficiently tested) commits and without having a convoluted branching strategy.
- jwestbury 3y agoOr: git reset --soft HEAD~1
- sbergot 3y agoprotip: If you want to switch branch you can now use "git switch [-c] foo". If you want to restore files you can do "git restore .". Basically you can stop using checkout. *edit*: fixed switch branch creation parameter.
- drdec 3y agoI think perhaps you meant "git switch [-c] foo"
- sbergot 3y agoCorrect thank you.
- Am4TIfIsER0ppos 3y ago"THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE." I will keep using them so I can keep using old software. How new is it? Does ubuntu or debian have it?
- Izkata 3y agoUntil it's actually removed, muscle memory will keep me using checkout.
- world2vec 3y ago`git add` sometimes
- Sharlin 3y agoI definitely can't work without `git add`. Other commands I use daily or almost-daily (frequently enough that I have aliases for them) are `git add -p`, `git commit --amend`, `git rebase`, `git rebase -i`, `git stash`... Then there's of course `git log`, `git diff`, and `git status`, but I presume you know about those as well.
- Patrol8394 3y agoTo cleanup the history before asking for a review. git rebase HEAD~2 -i git commit —amend
- mrkeen 3y agoFor me, git becomes unintelligible when there's a crazy train-track map of branching and merging. So I usually do whatever I can to keep a single straight-line master history. I branch off for a task, then after a while my branch isn't joined at the tip of master. So I rebase locally until it is. Then when the PR happens, master gets my changes added to the top, with no extra noise from merge commits. Even if the local-rebase workflow is slightly more complicated, the payoff is a really clean history, making future reasoning about branches much easier. Not to mention merge conflicts are easier to solve when you rebase early & often.
- yCombLinks 3y agoThat's because you've apparently used some command to look at that history, none of his commands ever show that
- remus 3y agoI think this is a pretty sensible approach. Git feels like one of those tools where you are given a lot of power but it's your responsibility to use it in a sensible way. A bit like with Excel or spreadsheets. You can do a lot but you can also make a big mess pretty quickly.
- silon42 3y agoIn my observation, the problem comes when there is a "merge main to the feature branch before merging" This step is when newbies get confused because the diffs are the wrong way, and I've seen people often losing merge hunks from master when there are conflicts which can be disastrous (not a git issue, I've seen people do the same in SVN). The proper solution IMO would be for git to have a "merge --reintegrate" which would do the opposite merge: take the main branch and merge the current feature branch to it... after success, you have a new feature branch. This is why I also prefer rebase and cleaner history (but a common mistake here is to squash after PR approval... that should be done before, not after).
- gumby 3y ago> For me, git becomes unintelligible when there's a crazy train-track map of branching and merging. Consider finding peace by inverting your perspective: if your organization’s development process (for whatever reason, many of them legitimate) involves a crazy train-track of features being developed in parallel, isn’t it great that you're all at least using something that can keep track of it? For a small team that should be unnecessary. Frequent rebasing when you’re on a side branch of development is smart, but doesn’t conflict with my point. Also, really, who looks back into the depths of history? There’s a reason a lot of backup schemes rotate a set of tapes over 30 or even 14 days. For that reason I am not a fan of rewriting history for “clarity”: I consider it wasted effort. For the same reason I don’t care about branches for explorations that turned out to go nowhere — just mark the head abandoned and stop worrying about it.
- saltserv 3y agoyou can't make do with only that if you're in a team of 2 even
- js2 3y agoGit is conceptually simple but has a baroque UI. I really recommend spending 15 minutes to understand it conceptually: objects: blobs, trees, commits, annotated tags refs: branches (local, remote-tracking), tags, HEAD other: working tree, index (aka cache aka staging area), remotes There's lots of good guides out there: git from the bottom up, git for computer scientists, and the git parable are some that spring to mind. The Git Book is also excellent but it's more than 15 minutes of your time. All the commands become way less mystifying when you understand what they are manipulating. You'll never get into a state where you want to `rm -rf` the entire repo and start with a new clone. There will hopefully be no more teeth grinding or keyboard mashing. I've used a lot of VCSs over the years (rcs, sccs, cvs, subversion, clearcase, mercurial, git) and I swear git is the one I find least frustrating. The others may have had simpler interfaces, but they were either conceptually more complex, overly rigid in their design and behavior, or both (looking at you clearcase). Look, I get it: a lot of folks see git as a necessary evil that's part of their day job. I disagree. I think it's really worth spending the time to learn well, probably like you invested some time in your editor and other tooling. I mean, it's easier than C++. :-)
- liotier 3y ago> The others may have had simpler interfaces, but they were either conceptually more complex, overly rigid in their design and behavior, or both Most of the time, I'll humbly trade "overly rigid in their design and behavior" for "simpler interfaces". Please master VCS, discipline me !
- GuB-42 3y agoYou are probably missing "git add" but otherwise, it is fine... unless you fuck up. Unfucking thing is what of most of my knowledge of git goes to. Committing in the wrong branch, the wrong files, starting from the wrong commit, etc... Before you push, almost all mistakes are fixable, but it requires knowing a few more commands. Then there are the project specific things. For instance, I worked on a project where we didn't have a central server we could push to and pull from (airgap). So we had to work with bundles. Git does that really well (it really is decentralized), but it is uncommon. Some people prefer a rebase-based workflow, some use cherry-picking extensively, some projects are more prone to conflicts than others, etc...
- 2-718-281-828 3y agoyou don't need git add? no git status? i take my hat off to you, sir!
- airstrike 3y agothat's my list too, pretty much (+ the obvious `git add` and `git status` others have mentioned) I throw in a `git reflog` once in a while, and the other day I patted myself on the back for my first use of `git tag -a mytag -m "This is my first tag!"` followed by `git push origin mytag`. I felt like god now as much as I hate Xcode, its UI for looking at all my current changes and staging them by blocks of line for commit is like a superpower. as a solo developer working on brand new code, not all of my lines of thinking follow very atomic git commits, so it's nice to separate, say, some refactoring code from some actually new functionality when committing changes
- dahart 3y agoYou’re definitely not the only one, but you will level up if you learn branching. After that you can become the guru amongst your peers and a god among men if you learn how to use ‘git reflog’. ;) That will help you learn how fix almost any git accident.
- paulddraper 3y agoReally?? I would have a very hard time without: git log git show git status git blame git diff git add git reset
- alex_smart 3y agoMy "minimalist" list of git commands: git add git blame git branch git checkout git cherry-pick git clone git commit git diff git fetch git log git merge git pull git push git reset git rm git stash git status 17 commands in total. I don't think it is possible to be a professional software engineer without being familiar with them. Granted, some of these you may need more frequently than others. My guess is, the OC relies on their IDE/editor for the functionality provided by some of these commands. But then, why not just go all the way. Just use all VC features provided by your IDE, and claim that you need zero git commands.
- chrisweekly 3y agoyou're def not the only one. but learning more pays dividends in confidence and resilience. fyi, pull is just shorthand for fetch && merge
- xorcist 3y agoUnless you are superhuman and never make mistaeks, you should put "git rebase" (with and without -i) on top of your list of things to learn.
- alex_smart 3y agoLet us also hope they do a git diff before pushing changes.
- deleted 3y ago[deleted]
- leonheld 3y agoI'm nothing without git rebase -i.
- bmacho 3y agoIf you get errors, save your work elsewhere, delete the project, and download a fresh copy.
- seba_dos1 3y agoYou don't need to know many more commands than those - maybe aside of "reset", "rebase" and "fetch" which definitely come handy regularly, and maybe a few more for showing status or browsing commit graph (unless you use some GUI for that) - as whenever you need anything else you'll usually just look it up anyway, either in the man or on the Web. However, if your mental model of git is limited to these commands only, you're doing yourself a disservice that leads to https://xkcd.com/1597/ https://xkcd.com/1597/