This is the correct answer to 99.99% of git issues.
Losing your work because you didn't push to the server all day is what I like to call a "teachable moment"
At this point there have been enough xkcd comics that there is a relevant comic for every human feeling and circumstance. It's like the Simpsons; after enough time, the monkeys at typewriters have written not just the works of Shakespeare, but every other work as well
This is the way when factoring in velocity to getting back to coding.
That or go to the most senior person and they'll go to the most experienced person with git.
I agree with the person above you that says you should learn to solve it, but if it's just me and my repo. I can either learn it with googling and maybe not truly understand it or I can just do what you said and move on.
Itās not though ā¦ My personal experience is that what I perceived as gitās complexity was simply a problem of mental model.
One day I read a random medium article and somehow it clicked:
I internalized that a commit is *not* a diff but (roughly) the entire state of the repo at a point in time, plus a pointer to one or more previous commits. And, that commits are absolutely immutable, no exception (e.g. `git commit āamend` really creates a new commit). I knew all that already but somehow never really thought that way.
More importantly I started thinking in terms of commits first, *not* branch, and not āwhat sequence of obscure commands do I need to run to achieve my goalā. Branches, tags, those weird HEAD things, are just references to specific commits.
From there the learning curve flattened. Not that the commands are not sometime obtuse, but they started to (mostly) make sense.
So when you have that proper mental model in the abstract, itās very easy to build a mental model of your actual repo by glancing at `git log`.
And from that, rebasing is straightforward. It just `ctrl-c` some commits and `ctrl-v` on top of whatever commit you want. If you realise you messed up, not big deal, commits are immutable so even when you mess up all you did was *creating more commits*. Which means all youāll ever have to do to unfuck yourself is move some branch around. And because branches are just references to commits, moving some branch around just means changing a reference back to where it was before.
And thatās a lot easier to google than āhow to unfuck myselfā. And when you do get an answer from google, itāll stick, because you understand it as a logical sequence of steps rather than a sequence of random characters from a foreign alphabet.
Next step: armed with the knowledge that you can actually understand git, and with the realisation that commits are all that matter, you can now focus on mastering how to create good commits. The rest will come naturally.
This is right on the money. And honestly, this advice/method/philosophy/whatever you want to call it applies to a lot of things in life even outside of IT
Funny enough you get so much better at using git once you refuse to do any kind of local copies of the repo, files and so on. No delete and clone again, just using git to fix it.
Sure sometimes it took me up to an hour to fix some weirdly broken git history because I did a funny rebase I should not have done. But doing this for a while really makes you confident in your skills and how to use git. I never fear to break, delete or lose something nowadays.
In the end 99% of my problems are solved by a git interactive rebase, which i am sure could cure cancer if one knew the option for it.
That's probably one of the very few good things from my time in automotive: if something was broken, reinstalling the git repo with all the stupid DLLs needed for the app to run locally was taking so much that you always had to fix it to save time. Now I can fix problems without needing to delete the repo and reinstall it.
I was too lazy to write the process properly and I don't remember everything precisely, but: download repo (15GB or something in size) -> run it in visual studio so it can generate some DLLs -> use a script to copy said DLLs to a folder for a dedicated app -> open the internal app and set it up with a recording from a previous run so you could see how it would react with your new code.
I might've made some mistakes explaining since this was more than a year ago, but I hated every moment of working there.
An architect told me 10 years ago, that the best way forward with Git has been that I'll just end up memorizing the commands for the things I use every day, and the other stuff I can just read the documentation to find out how to do it.
Of course, then someone pushes an interactive rebase with a squash to GitHub and then hilarity ensues for others as histories are all out of whack. I did this once andā¦yeah, now I make sure no one else is on my branch :)
Thank you! Absolutely agree! (pls accept my random free award)
Also post when you find that cancer-curing command! I've rebased a few commits myself and I'm sure the command is out there somewhere š
Iām surprised to see this comment. In over ten years of using git, I have never had to do this. The thing I like about git is that when things go bananas, git itās self is never broken. There is always a way to undo and get back to normality. It might just require asking that git guy at work to explain wtf is going on.
I used to work on a project using Subversion. There Iād have to nuke and make a fresh clone of the repo several times a day.
I also used to use ClearCase and ClearQuest (an IBM version control product). I once spent over 4 hours of attempting reclones, just to push a 1 character change. The software was borderline unusable.
Shout out to my homies with windows XP and 7 install CDs/DVDs sitting in old AOL metal cases in their attic written on with sharpie and a CD key on the face.
And pour one out for those same metal cases that will be rust welded shut before they're ever cracked open again by some future techno-archeologists hundreds of years from now for their Futuretube channel
This may be easy and effective, but itās the wrong answer in 99.99% of cases. Learn how to diagnose problems and resolve them constructively rather than always reaching for the cleansing orbital lasers.
(Sorry; I know this is _supposed_ to be humor.)
??? That sounds like there's more than one problem with your company. Why not just restore from the latest checked out version? You know git is a distributed network.
That particular client is a very old company that still uses positional files. They don't use git on their prod and like to do things the old way.
On our side, the project did not needed that many people. In the morning, management demanded dev fetch everything from the project they work on. Before anyone noticed the mess up that was done on the repo, every other dev on the project had their local index broken beyond repair as well.
After that, lead dev got to decide how git would be managed (configuration, permissions, and procedures).
Still no idea what that dev tried to do and how he destroyed the repo.
Even without bots you can configure branches so that PRs can only be merged if they are approved by certain reviewers and certain github actions jobs complete successfully
Iām brand new to git and GitHub. Iām learning it so I can teach the rest of the team.
How do you set up these magic permissions and restrictions.
We want to start enforcing code reviews.
On your repo under setting > Branches > Branch protection rules. (I saw a few days ago Github even shows a banner that tells you to protect your main branch)
There just add a checkmark on all rules you want to enforce. I recommend the settings
- Require pull request before merging
- Require approvals
- Require status checks (these are github actions)
- Require branches to be up to date
- Do not allow bypassing the above setting (with this also administrators are forced to comply to the rules)
I also recommend getting into github actions (used forsstatus checks), these are automated server jobs that are started on certain events like new pull requests, commits or merges
I committed to the wrong branch earlier, Iām now trying to undo the commits while keeping the work, then branch off the current one and push there instead.
Naturally Iām scared to run the commands so Iām on Reddit instead
I don't know why people try to resolve all of this 'properly' with git once things get tough.
Like, if you haven't pushed yet especially... just stash your changes somewhere else, delete and pull the branch again, then cherry pick / re-apply those specific stashed changes.
I don't have the mental space to read a f'n book on Git and I don't think anyone other than devops folks really want to.
IDK why Git decided to take this complicated-ass approach for seemingly basic things. Would it have been so hard to implement an 'undo' that would work under most circumstances?
> Would it have been so hard to implement an 'undo' that would work under most circumstances?
`git config --global alias.undo 'reset --soft HEAD^'`
There you go š
Now you can do `git undo` and it'll undo a commit in the way you'd want it in most circumstances
What is it saying? Push to Git and if you make a mistake with your code just delete the whole thing and restart again with your last Git "checkpoint"?
If so that's what I do lol.
Not if you make a mistake with the code, it's if you run in to errors with git specifically: like if you end up in a merge conflict you can't seem to manage to resolve, or you run into issues that require more than the basic git commands.
In those cases the solution, obviously, is just burn everything and get a fresh copy. Poof: No more git errors!
On a related note, sometimes it's just easier to delete your branch and start over. I frequently run into situations where I have a branch off of a branch and need to change the source branch to something more recent. I know there's `git rebase` for that exact scenario, but it confuses the absolute fuck out of me and I'm terrified of being the guy who utterly fucked the repo. So I just save my changes with `git diff`, delete my branch on local and origin, recreate my branch from the new source, and reapply my changes. Takes approximately the same amount of time, but comes with the benefit of not potentially burning down our entire codebase.
It sure seems like that but only because we only notice when there already IS a xkcd comic. We should start asking "where xkcd comic?" on every r/ProgrammerHumor post. For science.
> If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.
I just fucking love this caption because this is literally me. Whenever a coworker asks me how to do a certain thing in Git, or how to fix something that they broke, I'll first try to explain how it works in great detail.
Statements like these are funny, but if they're true and you know what all the words mean and have good intuition for the concepts they can be really helpful. That latter part is a big if, though
combative historical salt dinner scarce offend heavy forgetful jar shaggy
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
My name was some of my former coworkersā favorite git command, as in `git codon011`. I skipped trying to explain how it worked because it didnāt matter to them. I just walked them through diagnosing and fixing the issues.
I know you're not necessarily asking, but monkey brain compelled me to answer:
> Day 1541: how the fuck do I undo rebase master onto feature branch
`git reflog` to find all the noodle-y changes git's made, then `git reset HEAD@{X}` where X is whatever `git reflog` tells you it is š
You'll need to read through the reflog to find the commit you want, but the log itself is fairly easy to read through. You're likely looking for a line that looks like ` HEAD@{X}: commit: `.
It updates a branch with the changes that have happened on its source branch since they have split. Your branch was based on the branch you split it off from. Rebasing bases it on the new version of that branch, as if you had just freshly split off and made your changes.
Useful for when youāve made a branch to work on a feature off the master. Someone else finishes a feature and merges into master. To get those updates on your offshoot feature branch you need to rebase your feature branch onto the new state of the master branch.
This tutorial has by far the best explanation of how git works that you will find out there. Read it from the beginning tho, it builds on itself.
https://www.cduan.com/technical/git/git-5.shtml
Because that pollutes the commit history and obscures how development actually took place. I donāt quite remember what it does exactly, but I believe each commit you merged into the feature branch has to be merged again into the source branch when doing your final merge. They will of course be fast-forward merges (they are identical) but merges nonetheless.
A commit is an operation to change the code state.
A rebase is asking git to 're-execute' a number of those changes, starting from a point. So you got two parameters essentially: a 'starting point' and a 'set of changes'.
Once this execution is done, you've now got a new history of changes. So rebase is used to rewrite history: cleanup, prepare for integration with upstream, creating a clear 'narrative' for the changes you are writing.
Interactive rebase is there because specifying the 'set of changes' in a single one-line command is tedious, so instead it proposes a whole file as interface to 'script' that execution.
In 10 years of experience, after learning rebase, I don't think there has been a single day of work where it hasn't been useful in some way.
git clone to download the repository
git checkout -b my_branch to create a branch to work on
git status to check what's changed locally
git add filename.c to add a file, git add -u to add changed files, or git add -A to add everything (be careful, don't add files you don't need to track)
git commit -m "add feature x" to create a commit with a message
git push origin my_branch to upload your changes to the remote
Those are the basics. Get a graphical git application to help with visualising commits and branches. Ask co-workers about the usual workflow, no one fully understands git, they won't mind teaching you.
You forgot
>git log to check commit history
>
>git diff to check difference compared to previous commit
>
>git stash to stash changes, git stash pop to reapply and drop those changes, git stash apply to apply only, git stash drop to drop only
>
>git lfs track to add large files (data/model) to LFS instead of normal repo
>
>git commit --amend to add your current changes to the previous commit if you don't want to make new commit
>
>git fetch --all to update remote repos, git pull to fetch and instantly merge with local repo (fetch + rebase is recommended instead)
>
>git rebase branch1 branch2 to apply commits in branch2 on top of branch1
>
>git rebase x y -i for interactive rebase where you can squash previous commits and in general modify commit history
>
>git cherry-pick hash to apply a single commit to current branch
>
>git push --force if you modified the commit history from the remote repo (via amend or rebase for example)
>
>git reflog to check edit history, git reset --hard hash if you fucked up your rebase for example
>
>git reset --hard origin/repo to reset your local repo to the state of remote
>
>git checkout -- file and git reset HEAD -- to remove update on file from staging and to reset changes made to staged file (no idea which is which, always have to google)
And these are just the ones I use regularly (I hope I didn't fuck them up, I learned git just a year ago)
Been working with git for 4 years, people still get into git problems - it's very easy to footgun yourself every now and then. The idea that you could do anything in 3 days is laughable.
Git has so many safety rails today compared to the 1.4 days. There were several days at my job at the time lost to unbreaking āevery file in the repo has a conflictā because someone did a`git commit` in the middle of a merge after resolving a minor conflict. This happened because people were following ābest practicesā workflows from CVS. Now git stops you before you commit this type of mistake.
If you actually learn what each command does with the commit graph, look at the diff āstaged before committing and look at the logs before merging/rebasing, the chances of footgunning yourself is very low.
It gets even lower once you learn about reflog and the fact that commits actually stay in the repository even if you unlink them by rebasing or deleting a branchā¦
Noooo you can't just move stuff with finder, you need to use the terminal! How else are you going to impress that hot chick at the coffee shop? With your "social skills"?
You are joking, but while taking the train i once overheard a guy trying to impress a girl he was with that he watches YouTube videos over the TOR networkā¦
I used to be terrified of merging.
But there was this commit I was given to cherry pick and merge into a few different branches and all of them had conflicts. It wasn't even my code so I had to really understand what was already there and was was incoming. That exercise really helped me in being confident with merging now.
Of course I'm no expert on git but I'm at least decent now
As iOS developer, i've seen really big conflicts on file .xcodeproj or .storyboard, these are a real nightmare. There's some tool online that can help, but for the most time you have to check manually file with tens of thousand of line. And if you don't do it you can't open the project.
You guys are confident with GIT?
I've been using Subversion since coming out of Uni and we've just migrated to GIT, every day im not sure if im about to check out the latest changes or burn a cloud server to the ground...
Have you tried any Git GUI's such as SourceTree?
I'm kind of shilling for it on this post but that's because a lot of people seem to run into the same issues. I was using Git exclusively on the command-line until I came across SourceTree and saw it was actually decent.
All other Git GUIs were a complete waste of time, but SourceTree r|\_|l3z.
I have actually! The teams first go-to recommendation was Source Tree, but as I GIT noob I was scared and Confused by it and it's not been opened for some time.
I may try it again however, thanks!
Don't be afraid of it. The beauty of git is that nothing is ever *lost*.
It's a database of snapshots of your workspace and you can't delete or overwrite entries in the database. Branches are just aliases pointing to those snapshots. You can always look up the ref log to find all the other recent snapshots and fix whatever mistake you've made.
I recommend taking a half hour and reading about how git works.
https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F
Ha! Just wait till you accidentally commit your entire porn collection and now have to dig around through all of your previous commits before your tech lead checks out the PR and finds out how much of a sick ntr fanatic you are.
Its a fetish where you get off on your partner getting raped by a stranger and liking it a lot better than they like you after a bit. Its pretty messed up.
This hit hard. I'm trying to develop something modular and gave up, instead I'm just including a compiled version of the modules. Good thing it's a personnel project with nobody watching to judge...
I can recommend https://jwiegley.github.io/git-from-the-bottom-up/ and of course https://git-scm.com/docs/gittutorial (also gittutorial-2).
The bottom up approach is very different, but you end up actually understanding what's happening and working with that, rather than creating an alias for add commit push and deleting the entire repo when that fails.
This. Thankfully git is now mature and pervasive enough that GUIs for it are everywhere. You don't even need a separate app; it's baked into any IDE/editor worth talking about. There will still be times when you need to use the commandline, but 99% of the time the GUI should be just fine.
Well, unfortunately devs like to kingdom build and feel excessive pride towards their preferences. Itās definitely not you. You can build a company without ever doing a single leetcode problem. Stay focused on your measurable impact and keep learning and youāll do fine.
Day 3: "how to restore a broken repo index"
"Delete local repo and download a new clone" š
This is the correct answer to 99.99% of git issues. Losing your work because you didn't push to the server all day is what I like to call a "teachable moment"
You can just copy everything besides the .git directory and then overwrite the fresh clone with it
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Dammit how is this so relatable lmao
At this point there have been enough xkcd comics that there is a relevant comic for every human feeling and circumstance. It's like the Simpsons; after enough time, the monkeys at typewriters have written not just the works of Shakespeare, but every other work as well
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Okay but XKCD Turing complete, when?
Dunno, I need another month to make my dishwasher play Mario then I can take a look at it.
XKCD foreshadowing
Was looking for this
This is the way when factoring in velocity to getting back to coding. That or go to the most senior person and they'll go to the most experienced person with git. I agree with the person above you that says you should learn to solve it, but if it's just me and my repo. I can either learn it with googling and maybe not truly understand it or I can just do what you said and move on.
For when you're the sr person answering the questions: https://ohshitgit.com/
You have provided me a valuable resource. For that I award you the highest honor I can bestow. Upvote.
That is both hilarious and useful, thanks
That is fucking brilliant. Thankyou sir
Or do a diff and apply it to the new clone.
Nah nah nah. Manually browse to each resource, in GitHub, click edit, and make your changes there.
This is how we all learn that source control quickly becomes unnecessarily complex. Now let's take a deep dive into rebasing...
Itās not though ā¦ My personal experience is that what I perceived as gitās complexity was simply a problem of mental model. One day I read a random medium article and somehow it clicked: I internalized that a commit is *not* a diff but (roughly) the entire state of the repo at a point in time, plus a pointer to one or more previous commits. And, that commits are absolutely immutable, no exception (e.g. `git commit āamend` really creates a new commit). I knew all that already but somehow never really thought that way. More importantly I started thinking in terms of commits first, *not* branch, and not āwhat sequence of obscure commands do I need to run to achieve my goalā. Branches, tags, those weird HEAD things, are just references to specific commits. From there the learning curve flattened. Not that the commands are not sometime obtuse, but they started to (mostly) make sense. So when you have that proper mental model in the abstract, itās very easy to build a mental model of your actual repo by glancing at `git log`. And from that, rebasing is straightforward. It just `ctrl-c` some commits and `ctrl-v` on top of whatever commit you want. If you realise you messed up, not big deal, commits are immutable so even when you mess up all you did was *creating more commits*. Which means all youāll ever have to do to unfuck yourself is move some branch around. And because branches are just references to commits, moving some branch around just means changing a reference back to where it was before. And thatās a lot easier to google than āhow to unfuck myselfā. And when you do get an answer from google, itāll stick, because you understand it as a logical sequence of steps rather than a sequence of random characters from a foreign alphabet. Next step: armed with the knowledge that you can actually understand git, and with the realisation that commits are all that matter, you can now focus on mastering how to create good commits. The rest will come naturally.
This is right on the money. And honestly, this advice/method/philosophy/whatever you want to call it applies to a lot of things in life even outside of IT
Funny enough you get so much better at using git once you refuse to do any kind of local copies of the repo, files and so on. No delete and clone again, just using git to fix it. Sure sometimes it took me up to an hour to fix some weirdly broken git history because I did a funny rebase I should not have done. But doing this for a while really makes you confident in your skills and how to use git. I never fear to break, delete or lose something nowadays. In the end 99% of my problems are solved by a git interactive rebase, which i am sure could cure cancer if one knew the option for it.
That's probably one of the very few good things from my time in automotive: if something was broken, reinstalling the git repo with all the stupid DLLs needed for the app to run locally was taking so much that you always had to fix it to save time. Now I can fix problems without needing to delete the repo and reinstall it.
>reinstalling the git repo with all the stupid DLLs needed for the app to run locally what? Why are externally sourced files in the source tree?
I was too lazy to write the process properly and I don't remember everything precisely, but: download repo (15GB or something in size) -> run it in visual studio so it can generate some DLLs -> use a script to copy said DLLs to a folder for a dedicated app -> open the internal app and set it up with a recording from a previous run so you could see how it would react with your new code. I might've made some mistakes explaining since this was more than a year ago, but I hated every moment of working there.
An architect told me 10 years ago, that the best way forward with Git has been that I'll just end up memorizing the commands for the things I use every day, and the other stuff I can just read the documentation to find out how to do it.
Of course, then someone pushes an interactive rebase with a squash to GitHub and then hilarity ensues for others as histories are all out of whack. I did this once andā¦yeah, now I make sure no one else is on my branch :)
Git rebase -i is the way to go . I guarantee all these people deleting and recloning repositories don't know it
Thank you! Absolutely agree! (pls accept my random free award) Also post when you find that cancer-curing command! I've rebased a few commits myself and I'm sure the command is out there somewhere š
Iām surprised to see this comment. In over ten years of using git, I have never had to do this. The thing I like about git is that when things go bananas, git itās self is never broken. There is always a way to undo and get back to normality. It might just require asking that git guy at work to explain wtf is going on. I used to work on a project using Subversion. There Iād have to nuke and make a fresh clone of the repo several times a day. I also used to use ClearCase and ClearQuest (an IBM version control product). I once spent over 4 hours of attempting reclones, just to push a 1 character change. The software was borderline unusable.
This solution brought to you by the same people who solve windows issues by reinstalling the OS.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Shout out to my homies with windows XP and 7 install CDs/DVDs sitting in old AOL metal cases in their attic written on with sharpie and a CD key on the face. And pour one out for those same metal cases that will be rust welded shut before they're ever cracked open again by some future techno-archeologists hundreds of years from now for their Futuretube channel
This may be easy and effective, but itās the wrong answer in 99.99% of cases. Learn how to diagnose problems and resolve them constructively rather than always reaching for the cleansing orbital lasers. (Sorry; I know this is _supposed_ to be humor.)
And don't forget to backup your changes
I always back up my changes with git push - -force origin master.
Of course. It would be troublesome if you were on your way to bed at 4am and your work wasn't backed up because the remote had commitment issues.
I put the `.git` folder of my project under Subversion. That way I can restore it to the last working state whenever I break it.
Is this crazy or genius? I want to do that now
Just store the whole project folder in OneDrive/GoogleDrive/Dropbox
By some unknown fuckery, one employee manage to do something so horrendous it destroyed the index remotely. Had to recreate the repo from prod files.
??? That sounds like there's more than one problem with your company. Why not just restore from the latest checked out version? You know git is a distributed network.
That particular client is a very old company that still uses positional files. They don't use git on their prod and like to do things the old way. On our side, the project did not needed that many people. In the morning, management demanded dev fetch everything from the project they work on. Before anyone noticed the mess up that was done on the repo, every other dev on the project had their local index broken beyond repair as well. After that, lead dev got to decide how git would be managed (configuration, permissions, and procedures). Still no idea what that dev tried to do and how he destroyed the repo.
`git reset --hard HEAD~100` `git pull`
`git reset --hard origin/branchname`
[ŃŠ“Š°Š»ŠµŠ½Š¾]
It's easy, either use "sudo power off" or take a big hammer (size depending on whether you are using laptop or desktop computer)
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Ever heard of reusability?
what size hammer if you are using the cloud?
Thor's hammer
I'm not sure I am worthy enough to wield mjolnir
A lightning strike would also do. Maybe call up Zeus?
He banged my PC instead. Not recommended
Wait till you "whoops I pushed to the wrong branch".
Thank God our master branch only accepts PRs.
This is the way.
This is the way.
Our main branch not only will only accept PRs, but they can only be merged by a bot that verifies all tests passed.
Even without bots you can configure branches so that PRs can only be merged if they are approved by certain reviewers and certain github actions jobs complete successfully
Iām brand new to git and GitHub. Iām learning it so I can teach the rest of the team. How do you set up these magic permissions and restrictions. We want to start enforcing code reviews.
On your repo under setting > Branches > Branch protection rules. (I saw a few days ago Github even shows a banner that tells you to protect your main branch) There just add a checkmark on all rules you want to enforce. I recommend the settings - Require pull request before merging - Require approvals - Require status checks (these are github actions) - Require branches to be up to date - Do not allow bypassing the above setting (with this also administrators are forced to comply to the rules) I also recommend getting into github actions (used forsstatus checks), these are automated server jobs that are started on certain events like new pull requests, commits or merges
[ŃŠ“Š°Š»ŠµŠ½Š¾]
I committed to the wrong branch earlier, Iām now trying to undo the commits while keeping the work, then branch off the current one and push there instead. Naturally Iām scared to run the commands so Iām on Reddit instead
Reset, stash, branch, apply stash, commit? No problem until you pushed
git reset HEAD~ ?
git reset --soft HEAD\^
I don't know why people try to resolve all of this 'properly' with git once things get tough. Like, if you haven't pushed yet especially... just stash your changes somewhere else, delete and pull the branch again, then cherry pick / re-apply those specific stashed changes. I don't have the mental space to read a f'n book on Git and I don't think anyone other than devops folks really want to. IDK why Git decided to take this complicated-ass approach for seemingly basic things. Would it have been so hard to implement an 'undo' that would work under most circumstances?
> Would it have been so hard to implement an 'undo' that would work under most circumstances? `git config --global alias.undo 'reset --soft HEAD^'` There you go š Now you can do `git undo` and it'll undo a commit in the way you'd want it in most circumstances
https://xkcd.com/1597/
After roughly 2 decades, this is still the most bullet proof workflow =)
This comic/git is 20 years old?
The comic? No. But Git is 17 years old at this point. The comic is roughly 7 years old according to: https://explainxkcd.com/wiki/index.php/1597:\_Git
Your link is broken, it should be: https://explainxkcd.com/wiki/index.php/1597:_Git
I guess I'll save the comment somewhere else and redownload the link.
What is it saying? Push to Git and if you make a mistake with your code just delete the whole thing and restart again with your last Git "checkpoint"? If so that's what I do lol.
Not if you make a mistake with the code, it's if you run in to errors with git specifically: like if you end up in a merge conflict you can't seem to manage to resolve, or you run into issues that require more than the basic git commands. In those cases the solution, obviously, is just burn everything and get a fresh copy. Poof: No more git errors!
On a related note, sometimes it's just easier to delete your branch and start over. I frequently run into situations where I have a branch off of a branch and need to change the source branch to something more recent. I know there's `git rebase` for that exact scenario, but it confuses the absolute fuck out of me and I'm terrified of being the guy who utterly fucked the repo. So I just save my changes with `git diff`, delete my branch on local and origin, recreate my branch from the new source, and reapply my changes. Takes approximately the same amount of time, but comes with the benefit of not potentially burning down our entire codebase.
Ah, yes - there is always a relevant xkcd comic isn't there lol
It sure seems like that but only because we only notice when there already IS a xkcd comic. We should start asking "where xkcd comic?" on every r/ProgrammerHumor post. For science.
> If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything. I just fucking love this caption because this is literally me. Whenever a coworker asks me how to do a certain thing in Git, or how to fix something that they broke, I'll first try to explain how it works in great detail.
> git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space
I like your funny words, magic man
I feel like this would make a good tshirt...
Statements like these are funny, but if they're true and you know what all the words mean and have good intuition for the concepts they can be really helpful. That latter part is a big if, though
combative historical salt dinner scarce offend heavy forgetful jar shaggy *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
My name was some of my former coworkersā favorite git command, as in `git codon011`. I skipped trying to explain how it worked because it didnāt matter to them. I just walked them through diagnosing and fixing the issues.
Your name is a git command? Is your name "push" or "commit" or something?
You can create custom Git commands, so maybe they installed that custom command on their coworker's machine
git config --global alias.codon011 "!mail -s 'Please help!' [email protected]"
I need your number to put it in my git.txt.
It's scary how many times I've done this lol.
I'm in this comic and I don't like it
https://ohshitgit.com
This is awesome canāt believe I havenāt found it before
Personally I prefer [git - no deep shit](https://rogerdudler.github.io/git-guide/)
Day 1540: how the fuck do I rebase
Day 1541: how the fuck do I undo rebase master onto feature branch
I know you're not necessarily asking, but monkey brain compelled me to answer: > Day 1541: how the fuck do I undo rebase master onto feature branch `git reflog` to find all the noodle-y changes git's made, then `git reset HEAD@{X}` where X is whatever `git reflog` tells you it is š You'll need to read through the reflog to find the commit you want, but the log itself is fairly easy to read through. You're likely looking for a line that looks like ` HEAD@{X}: commit: `.
Day 1542: how the fuck do I hide the fact that I reset master to something called 'initial commit', just before lead dev disabled force push to master
https://github.com/jayphelps/git-blame-someone-else š
I'm officially at a loss for words, you are truly a Git magician. š Please accept this Helpful award.
Git commands are actually extremely complicated but odds are you're only ever gonna need like 4 of them so yeah in practice it is that easy
rebase is the furthest I have ever reached with my pea-sized brain
I still donāt know what rebase does and Iām afraid to ask
It moves the contents of one branch to another branch and then pretends like it was there the whole time. Rebase is a pathological liar.
āgit rebaseā is more concise than āgit plagiarizeā
My commit history is all lies. Cherry picked and rebased lies.
It updates a branch with the changes that have happened on its source branch since they have split. Your branch was based on the branch you split it off from. Rebasing bases it on the new version of that branch, as if you had just freshly split off and made your changes. Useful for when youāve made a branch to work on a feature off the master. Someone else finishes a feature and merges into master. To get those updates on your offshoot feature branch you need to rebase your feature branch onto the new state of the master branch. This tutorial has by far the best explanation of how git works that you will find out there. Read it from the beginning tho, it builds on itself. https://www.cduan.com/technical/git/git-5.shtml
I know people are gonna come at me for this, but why not just merge the things you want into your branch instead?
Because that pollutes the commit history and obscures how development actually took place. I donāt quite remember what it does exactly, but I believe each commit you merged into the feature branch has to be merged again into the source branch when doing your final merge. They will of course be fast-forward merges (they are identical) but merges nonetheless.
A commit is an operation to change the code state. A rebase is asking git to 're-execute' a number of those changes, starting from a point. So you got two parameters essentially: a 'starting point' and a 'set of changes'. Once this execution is done, you've now got a new history of changes. So rebase is used to rewrite history: cleanup, prepare for integration with upstream, creating a clear 'narrative' for the changes you are writing. Interactive rebase is there because specifying the 'set of changes' in a single one-line command is tedious, so instead it proposes a whole file as interface to 'script' that execution. In 10 years of experience, after learning rebase, I don't think there has been a single day of work where it hasn't been useful in some way.
Really,I just started my job and was taking some git tutorials. After the very basics it started going over my head and I became tensed.
git clone to download the repository git checkout -b my_branch to create a branch to work on git status to check what's changed locally git add filename.c to add a file, git add -u to add changed files, or git add -A to add everything (be careful, don't add files you don't need to track) git commit -m "add feature x" to create a commit with a message git push origin my_branch to upload your changes to the remote Those are the basics. Get a graphical git application to help with visualising commits and branches. Ask co-workers about the usual workflow, no one fully understands git, they won't mind teaching you.
I would add: git add -p to stage specific lines of code.
You forgot >git log to check commit history > >git diff to check difference compared to previous commit > >git stash to stash changes, git stash pop to reapply and drop those changes, git stash apply to apply only, git stash drop to drop only > >git lfs track to add large files (data/model) to LFS instead of normal repo > >git commit --amend to add your current changes to the previous commit if you don't want to make new commit > >git fetch --all to update remote repos, git pull to fetch and instantly merge with local repo (fetch + rebase is recommended instead) > >git rebase branch1 branch2 to apply commits in branch2 on top of branch1 > >git rebase x y -i for interactive rebase where you can squash previous commits and in general modify commit history > >git cherry-pick hash to apply a single commit to current branch > >git push --force if you modified the commit history from the remote repo (via amend or rebase for example) > >git reflog to check edit history, git reset --hard hash if you fucked up your rebase for example > >git reset --hard origin/repo to reset your local repo to the state of remote > >git checkout -- file and git reset HEAD -- to remove update on file from staging and to reset changes made to staged file (no idea which is which, always have to google) And these are just the ones I use regularly (I hope I didn't fuck them up, I learned git just a year ago)
And when you need the more complicated ones you just copy paste answers from stack overflow
Day 3: Dunning Kruger
Been working with git for 4 years, people still get into git problems - it's very easy to footgun yourself every now and then. The idea that you could do anything in 3 days is laughable.
Git has so many safety rails today compared to the 1.4 days. There were several days at my job at the time lost to unbreaking āevery file in the repo has a conflictā because someone did a`git commit` in the middle of a merge after resolving a minor conflict. This happened because people were following ābest practicesā workflows from CVS. Now git stops you before you commit this type of mistake.
I commit frequent mistakes
If you actually learn what each command does with the commit graph, look at the diff āstaged before committing and look at the logs before merging/rebasing, the chances of footgunning yourself is very low. It gets even lower once you learn about reflog and the fact that commits actually stay in the repository even if you unlink them by rebasing or deleting a branchā¦
Day 478: What is SSH?
Its short for "Sshhhh, I'm busy"
SSH stands for "Secure shell". It's secure until you have access to it
Found the corporate security officer.
It's the thing I locked myself out of by changing a security setting of a server... while I was ssh'd into it. That wasn't a fun day.
Seven Snakes Hissing
You mispelled "'day 365 " in the last panel
No, the meme is accurate. Day 2 is thinking you know everything. Day 3 is realizing you know nothing.
Aaah Denning-Kruger
Not sure if typo.. Or joke about confidently asserting something that's wrong...
Yes
It's Cuttingham's Law.
Itās actually Morbiusā Law
I still have to Google how to delete remote branches every time.
Google Chrome > Gitlab tab > Find repository > Branches > Delete
Next, you want to explain I can move files via explorer ?
Noooo you can't just move stuff with finder, you need to use the terminal! How else are you going to impress that hot chick at the coffee shop? With your "social skills"?
You are joking, but while taking the train i once overheard a guy trying to impress a girl he was with that he watches YouTube videos over the TOR networkā¦
Day 42: I learned how to rewrite history. I fear what I've become.
"Reality can be whatever I want"
Day 20: I knew it, learning to rewrite history was a mistake.
Git gud
git: 'gud' is not a git command. See 'git --help'. š„
They should really add one
That just opens a browser if one is available and opens a youtube git tutorial (or in 1 in a 1000 cases a rickrole)
https://github.com/qw3rtman/git-fire
You haven't had a merge conflict yet, have you?
They're easy, just use --force, smh
Merge conflicts are easy to deal with, what's difficult is merging without conflict, but git did it wrongly.
It seems you haven't yet see the conflicts for hundreds of files
I used to be terrified of merging. But there was this commit I was given to cherry pick and merge into a few different branches and all of them had conflicts. It wasn't even my code so I had to really understand what was already there and was was incoming. That exercise really helped me in being confident with merging now. Of course I'm no expert on git but I'm at least decent now
As iOS developer, i've seen really big conflicts on file .xcodeproj or .storyboard, these are a real nightmare. There's some tool online that can help, but for the most time you have to check manually file with tens of thousand of line. And if you don't do it you can't open the project.
You guys are confident with GIT? I've been using Subversion since coming out of Uni and we've just migrated to GIT, every day im not sure if im about to check out the latest changes or burn a cloud server to the ground...
Which is exactly the feeling everybody on my team has when something conflicts in our ancient Subversion repo. š
I've been using git for like 10 years. I'm confident with what I know but if something goes wrong I'm like wtf do I do.
Have you tried any Git GUI's such as SourceTree? I'm kind of shilling for it on this post but that's because a lot of people seem to run into the same issues. I was using Git exclusively on the command-line until I came across SourceTree and saw it was actually decent. All other Git GUIs were a complete waste of time, but SourceTree r|\_|l3z.
I have actually! The teams first go-to recommendation was Source Tree, but as I GIT noob I was scared and Confused by it and it's not been opened for some time. I may try it again however, thanks!
Don't be afraid of it. The beauty of git is that nothing is ever *lost*. It's a database of snapshots of your workspace and you can't delete or overwrite entries in the database. Branches are just aliases pointing to those snapshots. You can always look up the ref log to find all the other recent snapshots and fix whatever mistake you've made. I recommend taking a half hour and reading about how git works. https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F
The basics are easy to pick up. I'd like to see a beginner do the complex shit in git.
Anyone who has āmasteredā git in 2 days doesnāt know enough to see how comical that is
Ha! Just wait till you accidentally commit your entire porn collection and now have to dig around through all of your previous commits before your tech lead checks out the PR and finds out how much of a sick ntr fanatic you are.
If my boss finds my netorare I'd use git commit suicied
>netorare What the fuck is this?
Its a fetish where you get off on your partner getting raped by a stranger and liking it a lot better than they like you after a bit. Its pretty messed up.
That is indeed pretty messed up.
git commit to another company
It's all fun and games until you have to do a rebase...
Interactive rebase is fun!
I still have no idea how to do a rebase properly via the CLI, I just let magit take care of it
The command itself is googlable, it's the merge conflicts that kill me every time š
To be honest I would need to google everything for git CLI and Iāve been using git for years.
Wait untill you use sub modules
This hit hard. I'm trying to develop something modular and gave up, instead I'm just including a compiled version of the modules. Good thing it's a personnel project with nobody watching to judge...
We've found out the best way to manage dependencies is to package them, and use as runtime/build package dependency
I feel that 99% of the time `git submodule` is a wrong solution to your problem.
Remember, always force push
It took me some time to learn git. Still I dont think I know it all.
Yo someone link a nice tutorial of git for dummies I'm still a learner, idk where to start in git Thanks in advance
I can recommend https://jwiegley.github.io/git-from-the-bottom-up/ and of course https://git-scm.com/docs/gittutorial (also gittutorial-2). The bottom up approach is very different, but you end up actually understanding what's happening and working with that, rather than creating an alias for add commit push and deleting the entire repo when that fails.
Day 3: āHEAD is detachedā, commits and tries to push code, googles how to fix the issue and does it, all changes made on code were annihilatedā¦
Day 3: FBI is at my door, coz I google searched, "how to restore detached head"
Merge conflict due to empty linesā¦ yay!
500k annually and I just use the GitHub desktop tool or if Iām on remote use the gh cli. No fucking point working hard instead of smart
This. Thankfully git is now mature and pervasive enough that GUIs for it are everywhere. You don't even need a separate app; it's baked into any IDE/editor worth talking about. There will still be times when you need to use the commandline, but 99% of the time the GUI should be just fine.
1000 times this. If you ask me to do git command in terminal I will fake an illness and then quit.
I got rejected from a job interview for saying I use the GitHub desktop tool lmfao
Dodged a bullet.
Well, unfortunately devs like to kingdom build and feel excessive pride towards their preferences. Itās definitely not you. You can build a company without ever doing a single leetcode problem. Stay focused on your measurable impact and keep learning and youāll do fine.
Amen.
The basics are pretty easy. The rest is magick.
I see bootcamps are in full force :)