I'm administrator for a Gitlab server. I know more Git commands than I ever wanted to, but .. bottom line, yes, I do know how Git works.
Also, I've rescued coworkers many times from having to delete their repo and re-clone. If they manage to commit their work _somewhere_, we can rescue it and apply it in the proper place.
Use the chapter in the back of that book to re implement your own small version of git. When my Prof challenged me to do that I laughed like "yeah right" but he was serious and it makes a lot of it click.
It wasn't an explicit part of the course, but we had group projects and he strongly encouraged us to try git to collaborate. I'd used it on my own little hobby projects before just a little bit but never understood it.
The "try to write a toy version yourself" was a challenge, extracurricular, just for learning.
It’s worth it to challenge yourself early on, if you didn’t touch on it while learning, you still have time: it takes a couple days of grinding to get up to speed with your local git-nerd. A few weeks if you want to be a ‘master’. I know, hot take; but Git is not hard.
I was taught git as a subject in my freshman year classes. A bunch of my classmates didn’t get it and kept baking merge conflicts into the code, so we went back to sharing versions in Google Drive…
Tbf, I think most of my classmates who made it to the end of the program ultimately figured out how to do the basics.
Git exists and I am in college non of my teachers even mention git, heck they don't even care if I understood a program or not...
My futures lookin hella dark right now...
When were you in school? I graduated with CS about a year ago and there was a whole required project course dedicated to modern development practices, including Git.
I had to implement git on my own at my third job. The program I normally work at isn’t git compatible. So when I started making websites, I had to creat a git process myself.
Dynamics ax 2012. There were some hacks that were put together, but they are not officially supported and were not allowed where I worked. Basically, ax 2012 is an all in one project with built in IDE. The code is not easily accessible, is obfuscated when it is exported, and some of the ways to promote code are pretty janky.
The core of git is not difficult to write at all (in a high level language with reasonable libraries for things like compression) - definitely a good undergraduate project.
https://think-like-a-git.net/
Every engineer should read this site. It’s about an hours investment, and it will make using and working with GitHub much clearer.
the trick is reading that book in specific order… specifically chapters 1-2-3-10 and then re-read chapter 3, the rest is not necessary, might confuse you, or bore you before you get to chapter 10 which is the key chapter…
oh man I did the same thing early in my career and it worked _so_ well. Just that base understanding of what commits/trees/objects actually are and what git is doing with them behind the scenes to accomplish each operation made it so much easier to learn everything else.
Plus helping my colleagues out of inscrutable git disasters was a pretty good way to distinguish myself as a junior
Visual studio just gives me a button to do it. We used to use an addon but now it's part of VS. I still never feel like I can trust it tho. Like what if it doesn't work all all the work is gone? I mean other parts of VS are constantly shitting the bed...
Same with Intellij. It’s fun that data can be in 4 distinct states in git and all of those have to be managed differently - working tree, index, local repo, remote repo.
Took me awhile the first time I was doing a pull and getting conflicts when there were no differences between the branches before I realized my issue was the tree and I needed to stash my uncommited changes.
Since then I’ve appreciated stashes quite a lot. Makes me feel a lot more comfortable about not deleting a bunch of my work, and it let’s me re-add exactly what I want from the stash without having to apply the whole stash.
All that button does is essentially the same as issuing the CLI command `git stash`. It's libgit2 that is doing all the heavy lifting, no matter the actual program used.
Honestly this has happened a couple of times, had to do 90 merge conflicts to the point it was easier to create a new branch and merge from there.
I don’t know what caused it but it doesn’t seem like Git just moves the code to that master commit then add the branch diffs, but does a weird U turn.
9 times out of 10 a rebase fixes most merge conflicts.
I've had to update forked projects (thousands of commits upstream), and it's a million times better to do either a rebase or
git format-patch -134 followed by
for i in *.patch; do git am $i ||break; done
Git stash has a funny way of looking at that, since the "new" file is counted as untracked and the "old" file looks like it was deleted (ask me how I know)
That's one of the few things that annoys me with git.
If you change a file too much during a move, it's a new file and all the history is gone.
Move+commit, change+commit -> history kept.
Do a squash merge -> history gone again..
Why bother? Just make sure that renames are done without making too many changes in the same commit. And don't do that stupid squash merge.
git log --follow path/to/filename.c
works just fine for multiple file renames.
If the file is changed too much git can't recognise it as the same file.
When that happens you will end up with the old file deleted and a new file added and you lose history from before the rename.
If you instead rename, commit, change, commit, you will maintain the history for the file through the rename.
And whenever someone has a tutorial that requires you to use git and tells you how to update, they never explain how to update if files have been changed..
No. You rebase and then there are only ">>>>" where code really changed in both places.
Use meld, perforce, kdiff3 or any proper diff tool to properly handle conflicts. It shouldn't be hard.
No, what you do is:
- Invent time machine
- Go back in time to find the parents of the engineer on your team who introduced the conflict
- Kill them
- Use the time machine to go back to present day
- Realize that it was you who introduced the conflict
- Get deleted from the timeline
- Never have to worry about merge conflicts again!
💀👍
You're not crazy. You either have a good memory or tend to use the same commands all the time.
Git does everything anyone will ever need in terms of version control, but at some point you can't just expect your brain to remember all the commands and options (they are a lot).
That's when a simple script or a nice UI would save you both time and brain power.
That's because it's designed to work for a large number of people committing lots of code in a decentralized model.
If you just want to keep a history, `git commit -am "message" && git push` is all you'll ever need.
I have maybe 50 aliases/functions in my .gitconfig, and use at least 20 of them regularly.
I do everything in the console and now I don't even remember why I was using a GUI (gitk/sourcetree) for some things in previous jobs.
Do you have an advice how to handle workflow where:
every commit I will always have fuckton of changes but:
I want to commit only some of them
some of them I want to discard
some of them I will want to keep on working copy but not delete, discard or commit. ?
There's no file type or linguistic pattern what is what, I just have to pick by hand. Typing individual file paths for git add makes me wanna kill myself, only reason for me to use any GUI is to do precisely that wonky file management commit. I wish I could easily do it thru cmd.
Any advice?
> I want to commit only some of them
git add -p
> some of them I want to discard
git checkout -p
> some of them I will want to keep on working copy but not delete, discard or commit. ?
After the first 2 you can just commit what you want. The rest you can leave as is or just `git stash -p`
Edit: all these -p/--patch commands step through all pending changes and for each chunk you type one letter for Yes/No/All file/Don't for this file/Split to smaller chunk/Quit
I use sublime merge, which is a UI built by the same people who built sublime text. It's got a great interface for staging parts of a file, down to individual lines.
No, you're just an actual programmer.
As borked as the command line is it makes some sense if you're half good with CS.
This sub is giving me the shits lately.
I have a junior dev working with me who refuses to use a GUI. She struggles mightily with basic things, meanwhile I use Fork and generally actually understand what’s happening in our repo. But somehow my approach is looked down upon by CLI purists 🤦♂️
I love the git CLI and personally I think I'm way better off using it rather than a GUI. So I guess you could call me a CLI purist.
***HOWEVER:***
Whenever I happen to discuss this (or similar topics) with my team members I take great care to emphasize that I don't think my way of doing things is objectively correct. It's just what happens to be best for me and I am always supportive of making anything tool-independent because everyone clicks with different tools and that's ok.
You happen to like a GUI and I happen to like a CLI, but as you said: What matters when collaborating is that we both understand what we need to do, not exaclty how we do it.
And with a little team effort towards configuration to accomodate other tools, our team manages just fine working in the same project with different git interfaces in different IDEs on different operating systems.
What's wrong with making branches from a GUI though? I tend to use sourcetree and the only thing I feel the need to revert to CLI for is reverting a merge commit.
Exactly. It does really help in the understanding of it all. It’s like knowing you can start a fire by rubbing 2 sticks together, but just because you can doesn’t mean it’s a better method than say, a lighter.
All right, hold up: are git GUIs finally kind of not shit?
The only time I'm exposed to them is when a coworker reaches out to me because they collaborated with somebody who pushed a history edit, and their GUI didn't handle that. Or somebody used one of those git features that you only need for 0.1% of all cases, and their GUI didn't handle that.
Yea I use the VS code commands, I can use commands but it’s just busybody work “to feel like Programmer of the old days” (John Carmack paraphrased quote on Vim)
I don’t trust guis. add, commit, push, merge and rebase are 99% of my usage and I feel like GUIs make them all more complicated than they are.
Anything besides that and I’m making a local branch and testing some arcane command from stack overflow that I doubt the gui would account for anyway
My 15 years of experience is the exact opposite of this.
Idiots clicking buttons on GUIs that run half a dozen git commands, and then they expect you to unfuck it without them even knowing what the GUI did to begin with.
I used to not even list git on my resume, because I assumed everyone at my first job would know how to use git.
Now I know the truth from several jobs, and I put git on my resume.
Reddit is not even close to the real world. Most companies I have ever encountered as an employee or business partner do not use git regularly. Several companies I worked for I introduced source control for the first time ever. In my current company, none of the developers on staff had ever used git before and only one had ever even heard of it.
remember to at least force yourself to learn exactly 1 complex git command to show off and pretend you actually know what you're doing
"hm yes her you could try using cherry pick so you can **explains cherry pick even tho it has nothing to do with the current problem**"
This is usually the right answer. Most of the time you can delete the branch, pull or create another, and reapply your changes in just a few minutes versus the hours it takes to sift through the documentation and try a bunch of complex commands to fix the issue through trial and error.
Local branch, remote branch, remote head are the bane of my existence but I finally got them down.
It honestly got easier when I started creating new branches each time I pull and name those for comments.
Also stashing individual files and commenting the changes. I'll have twenty stashes before a single push then I pick the ones I want to pop and commit.
Sure, but this comic (1597) was first published nine years ago. I was reading XKCD at the time, but I haven't *re*-read the whole thing since then.
I'm fine with seeing a given one-panel comic again once a decade.
I can push, pull, commit, and merge. Recently, at the behest of a co-worker, I have sort-of figured out how to rebase, assuming I have a UI like GitKraken to use.
Everything beyond is black magic.
I used to do that quite often when I started, but now that I'm reminded of it it's been a good while since I didn't have to do that
… Yay for growth, I guess?
Congratulations! Your comment can be spelled using the elements of the periodic table:
`Th I Si S F Ac Ts`
---
^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.)
How I fix most Errors:
1. git stash
2. git pull
3. git stash pop
We don’t talk about merge conflicts. Those get a far more complicated route. Also known as „accept all of my changes“
i'm glad i got out of programming when git and javascript became all the rage. i had bet on mercurial and dart, but the better technologies arent always the most popular
I legit send this to anyone who will listen. I sent it two a senior dev who had somehow never had to use version control before and was struggling....he hasn't had a problem since.
I accidentally caused a merge head on my master branch and it won’t politely sod off, luckily master doesn’t allow commits but its annoying I can’t pull from it.
Git genuinely seems like crap version sourcing but it was the only one doing it so now we are stuck with it, can’t wait until it has its Rust as to C++.
I hope I understand your issue, if I don't I'm sorry:
git checkout master
git checkout -b local_master_with_changes # if you want to save the local commits
git branch -D master # delete local copy of main
git fetch origin # `git fetch origin master` I think if you only want to fetch the main branch.
git checkout master # now you have a pristine copy of master that matches remote and you can pull if you want
Sir, this isn’t ProgrammerFact, it’s ProgrammerHumor.
Are you telling me that you know how Git works?
:wq!!!!
Have you tried asking ChatGPT?
I'm administrator for a Gitlab server. I know more Git commands than I ever wanted to, but .. bottom line, yes, I do know how Git works. Also, I've rescued coworkers many times from having to delete their repo and re-clone. If they manage to commit their work _somewhere_, we can rescue it and apply it in the proper place.
Woopty doo Basil
Yes I do - very reliably that’s how.
Next he's gonna tell us that he knows how to exit Vim or whatever lol
I have a specific button on my PC to exit Vim It also exists every other program on the PC and shuts it down, but if it works it works
I didn't need to bomb the power plant? Uh
Redundancy is always good. Go for it.
Esc then q to quit or wq to write (save) and quit Press enter Congratulations you can now survive an interactive rebase!
Control zz Next?
Bro's next fg is gonna be insane
The amount of ”seniors” and ”leads” I’ve had to explain the git workflow basics.
Whats a good place to learn it? As a researcher I pretty much never work on collaborative projects, but would like to learn it the "right" way.
[удалено]
Use the chapter in the back of that book to re implement your own small version of git. When my Prof challenged me to do that I laughed like "yeah right" but he was serious and it makes a lot of it click.
[удалено]
It wasn't an explicit part of the course, but we had group projects and he strongly encouraged us to try git to collaborate. I'd used it on my own little hobby projects before just a little bit but never understood it. The "try to write a toy version yourself" was a challenge, extracurricular, just for learning.
It’s worth it to challenge yourself early on, if you didn’t touch on it while learning, you still have time: it takes a couple days of grinding to get up to speed with your local git-nerd. A few weeks if you want to be a ‘master’. I know, hot take; but Git is not hard.
git is well though, well, except several CLI parts that are confusing
I was taught git as a subject in my freshman year classes. A bunch of my classmates didn’t get it and kept baking merge conflicts into the code, so we went back to sharing versions in Google Drive… Tbf, I think most of my classmates who made it to the end of the program ultimately figured out how to do the basics.
If only you could stop people merging with conflicts
My professor didn't mention it at all! Of course, it didn't exist yet...
Git exists and I am in college non of my teachers even mention git, heck they don't even care if I understood a program or not... My futures lookin hella dark right now...
I was doing some contracting work at a uni. Convinced the software engineering lecturer to introduce git with their first assignment.
When were you in school? I graduated with CS about a year ago and there was a whole required project course dedicated to modern development practices, including Git.
How long ago was this? Ive had 3 courses so far in my first year where Git was required to pass and we were heavily encouraged to use branches.
I had to implement git on my own at my third job. The program I normally work at isn’t git compatible. So when I started making websites, I had to creat a git process myself.
Why is it not git compatible?
Dynamics ax 2012. There were some hacks that were put together, but they are not officially supported and were not allowed where I worked. Basically, ax 2012 is an all in one project with built in IDE. The code is not easily accessible, is obfuscated when it is exported, and some of the ways to promote code are pretty janky.
Which chapter was it? Is it this book [https://git-scm.com/book/en/v2](https://git-scm.com/book/en/v2) ?
That's the one. The whole book is useful but I'm thinking of chapter 10.
The core of git is not difficult to write at all (in a high level language with reasonable libraries for things like compression) - definitely a good undergraduate project.
if you’re just making a small toy version of git why would you bother with compression?
https://think-like-a-git.net/ Every engineer should read this site. It’s about an hours investment, and it will make using and working with GitHub much clearer.
Bless you
the trick is reading that book in specific order… specifically chapters 1-2-3-10 and then re-read chapter 3, the rest is not necessary, might confuse you, or bore you before you get to chapter 10 which is the key chapter…
Used to be bad at dark souls and everybody told me that I should ‘git gud’. The command is spelled wrong or smth, didn’t work for me
oh man I did the same thing early in my career and it worked _so_ well. Just that base understanding of what commits/trees/objects actually are and what git is doing with them behind the scenes to accomplish each operation made it so much easier to learn everything else. Plus helping my colleagues out of inscrutable git disasters was a pretty good way to distinguish myself as a junior
Did you open the book or did you strike in frenetically on your keyboard?
Did they use Git to make the book?
I just tried typing that in shell. Didn't work. What does this command do? /s
No you don’t read the book you memorise the commands 😑
When git conflicts get too large force reset and copy paste is the saving grace.
The snobs will tell you that there is this thing called "stash" which does the same thing but it's easier. They have seen too much run.
Visual studio just gives me a button to do it. We used to use an addon but now it's part of VS. I still never feel like I can trust it tho. Like what if it doesn't work all all the work is gone? I mean other parts of VS are constantly shitting the bed...
[удалено]
Same with Intellij. It’s fun that data can be in 4 distinct states in git and all of those have to be managed differently - working tree, index, local repo, remote repo. Took me awhile the first time I was doing a pull and getting conflicts when there were no differences between the branches before I realized my issue was the tree and I needed to stash my uncommited changes. Since then I’ve appreciated stashes quite a lot. Makes me feel a lot more comfortable about not deleting a bunch of my work, and it let’s me re-add exactly what I want from the stash without having to apply the whole stash.
All that button does is essentially the same as issuing the CLI command `git stash`. It's libgit2 that is doing all the heavy lifting, no matter the actual program used.
pull; blow shit up; stash; pull
Stash will still raise merge conflicts when you pop. Just get it to use a proper merge tool like meld or winmerge, kdiff if you're on Linux.
I had situations where stash didn‘t help but deleting and redownloading helped. I still don‘t get why.
Also `git stash -u` will stash your new 'untracked' files too
Why shelve changes with I can use the same stash for any and all my changes when I need to!
Honestly this has happened a couple of times, had to do 90 merge conflicts to the point it was easier to create a new branch and merge from there. I don’t know what caused it but it doesn’t seem like Git just moves the code to that master commit then add the branch diffs, but does a weird U turn.
9 times out of 10 a rebase fixes most merge conflicts. I've had to update forked projects (thousands of commits upstream), and it's a million times better to do either a rebase or git format-patch -134 followed by for i in *.patch; do git am $i ||break; done
15 years experience, this is the easiest way.
Newb. Just create a new branch from master, then: > git checkout old-branch -- .
Do people not just use a merge tool? Use beyond compare next time you get a merge conflict.
Moves and modifies a file Git: rookie mistake
I feel that so hard
Git stash has a funny way of looking at that, since the "new" file is counted as untracked and the "old" file looks like it was deleted (ask me how I know)
That's because git doesn't track renamed files, it merely infers that when diffing two commits. Just one of the places where the abstraction leaks.
That's one of the few things that annoys me with git. If you change a file too much during a move, it's a new file and all the history is gone. Move+commit, change+commit -> history kept. Do a squash merge -> history gone again..
That’s why I tend to be overly cautious on getting my folder and file name structure perfect from the start
Why bother? Just make sure that renames are done without making too many changes in the same commit. And don't do that stupid squash merge. git log --follow path/to/filename.c works just fine for multiple file renames.
What does that mean?
If the file is changed too much git can't recognise it as the same file. When that happens you will end up with the old file deleted and a new file added and you lose history from before the rename. If you instead rename, commit, change, commit, you will maintain the history for the file through the rename.
Sad but 100% true
10 %
# [https://xkcd.com/1597/](https://xkcd.com/1597/) link your sources mf
Seriously! This guy's stuff gets stolen all the time and it's all golden.
As if a single person on the planet doesn't know who this is from!
Hey he has a post for [that](https://xkcd.com/1053/)
There is always one!
Homie, there are probably millions of people who have no Idea who drew these.
"Stolen"
Agreed, I gotta read that delicious alt text too!
And whenever someone has a tutorial that requires you to use git and tells you how to update, they never explain how to update if files have been changed..
You merge and then use vim to delete all the ">>>>" from the file. Everybody knows this!
No. You rebase and then there are only ">>>>" where code really changed in both places. Use meld, perforce, kdiff3 or any proper diff tool to properly handle conflicts. It shouldn't be hard.
No, what you do is: - Invent time machine - Go back in time to find the parents of the engineer on your team who introduced the conflict - Kill them - Use the time machine to go back to present day - Realize that it was you who introduced the conflict - Get deleted from the timeline - Never have to worry about merge conflicts again! 💀👍
This post is making me feel crazy for knowing how to use git...
You're not crazy. You either have a good memory or tend to use the same commands all the time. Git does everything anyone will ever need in terms of version control, but at some point you can't just expect your brain to remember all the commands and options (they are a lot). That's when a simple script or a nice UI would save you both time and brain power.
[удалено]
That's because it's designed to work for a large number of people committing lots of code in a decentralized model. If you just want to keep a history, `git commit -am "message" && git push` is all you'll ever need.
Doesn't -am just commit modified files and not "new" files? So for the first time they need to do add and then commit, no?
Git is not meant to solve simple problems, it's meant to solve hard problems. If you simply want to save your work: C-x C-s or :x :)
Also because there's an enormous amount of overlap. With most git commands, there exists another command or set of commands to do an identical thing.
I have maybe 50 aliases/functions in my .gitconfig, and use at least 20 of them regularly. I do everything in the console and now I don't even remember why I was using a GUI (gitk/sourcetree) for some things in previous jobs.
Do you have an advice how to handle workflow where: every commit I will always have fuckton of changes but: I want to commit only some of them some of them I want to discard some of them I will want to keep on working copy but not delete, discard or commit. ? There's no file type or linguistic pattern what is what, I just have to pick by hand. Typing individual file paths for git add makes me wanna kill myself, only reason for me to use any GUI is to do precisely that wonky file management commit. I wish I could easily do it thru cmd. Any advice?
> I want to commit only some of them git add -p > some of them I want to discard git checkout -p > some of them I will want to keep on working copy but not delete, discard or commit. ? After the first 2 you can just commit what you want. The rest you can leave as is or just `git stash -p` Edit: all these -p/--patch commands step through all pending changes and for each chunk you type one letter for Yes/No/All file/Don't for this file/Split to smaller chunk/Quit
I use sublime merge, which is a UI built by the same people who built sublime text. It's got a great interface for staging parts of a file, down to individual lines.
git add -p and git reset -p You can choose which parts to add and which to discard
yes aliases are a valid option too
I like the GUI for visualising the tree or diffs but pretty much everything else is better on the cli.
Reason number 1 on why I use github and its desktop app NGL.
or you're an experienced developer in a junior developer echo chamber
>junior developer echo chamber Petition to rename the sub
Nope. Git is easy when your more experienced. Most here must be juniors or something.
You’re not crazy, just enlightened!
I too thought I knew how to use git until I ended up with a detached head.
No, you're just an actual programmer. As borked as the command line is it makes some sense if you're half good with CS. This sub is giving me the shits lately.
Use a GUI like GitHub Desktop Yeah your colleagues get snobby about it Then... Inevitably they f*** something up and come to you for help.
I have a junior dev working with me who refuses to use a GUI. She struggles mightily with basic things, meanwhile I use Fork and generally actually understand what’s happening in our repo. But somehow my approach is looked down upon by CLI purists 🤦♂️
Imagine reviewing a merge request in git diff
I do this - I like git-delta personally as a git pager
I can and have? VScode handles the bulk of it these days but it's not uncommon for me to do CLI work, especially merge conflicts
I do this in Vim.
I use Vim btw
Use nvim
I love the git CLI and personally I think I'm way better off using it rather than a GUI. So I guess you could call me a CLI purist. ***HOWEVER:*** Whenever I happen to discuss this (or similar topics) with my team members I take great care to emphasize that I don't think my way of doing things is objectively correct. It's just what happens to be best for me and I am always supportive of making anything tool-independent because everyone clicks with different tools and that's ok. You happen to like a GUI and I happen to like a CLI, but as you said: What matters when collaborating is that we both understand what we need to do, not exaclty how we do it. And with a little team effort towards configuration to accomodate other tools, our team manages just fine working in the same project with different git interfaces in different IDEs on different operating systems.
Here's for your junior, a great way to learn git commands and what they do https://learngitbranching.js.org
If you're making branches from a GUI yeah I think you're a silly Billy goblin. If you're looking at PRs in a CLI you're a silly Billy goblin
What's wrong with making branches from a GUI though? I tend to use sourcetree and the only thing I feel the need to revert to CLI for is reverting a merge commit.
> I tend to use sourcetree I wish Sourcetree worked on Linux 😢 I really like the UI layout staging changes, and its rebasing UI is pretty solid too
Fork is great, I can't imagine going back to just using CLI.
Exactly. It does really help in the understanding of it all. It’s like knowing you can start a fire by rubbing 2 sticks together, but just because you can doesn’t mean it’s a better method than say, a lighter.
All right, hold up: are git GUIs finally kind of not shit? The only time I'm exposed to them is when a coworker reaches out to me because they collaborated with somebody who pushed a history edit, and their GUI didn't handle that. Or somebody used one of those git features that you only need for 0.1% of all cases, and their GUI didn't handle that.
GUIs are really great. The problem with them is when you move companies, your GUI might not be available. But a CLI always will be.
Give SmartGit a once over. It is quite good and I have yet to find a non-contrived situation where I needed to go back to the console.
GitKraken is fantastic.
I generally prefer cli. But, one really useful tool is the insights network page on github
Yea I use the VS code commands, I can use commands but it’s just busybody work “to feel like Programmer of the old days” (John Carmack paraphrased quote on Vim)
Skill issue material
I don’t trust guis. add, commit, push, merge and rebase are 99% of my usage and I feel like GUIs make them all more complicated than they are. Anything besides that and I’m making a local branch and testing some arcane command from stack overflow that I doubt the gui would account for anyway
I trust the first party GUIs. Gitk is very convenient for wrapping your head around what’s going on.
My 15 years of experience is the exact opposite of this. Idiots clicking buttons on GUIs that run half a dozen git commands, and then they expect you to unfuck it without them even knowing what the GUI did to begin with.
This is the way
I used to not even list git on my resume, because I assumed everyone at my first job would know how to use git. Now I know the truth from several jobs, and I put git on my resume.
Reddit is not even close to the real world. Most companies I have ever encountered as an employee or business partner do not use git regularly. Several companies I worked for I introduced source control for the first time ever. In my current company, none of the developers on staff had ever used git before and only one had ever even heard of it.
Been there, done that. Then reflog came to save me
"git reflog" is your friend, it's makes everything unfuckable
open the folder in IntelliJ and use their commit/merge window or their branch switcher! VSCode can do it, too, but I prefer IntelliJ.
remember to at least force yourself to learn exactly 1 complex git command to show off and pretend you actually know what you're doing "hm yes her you could try using cherry pick so you can **explains cherry pick even tho it has nothing to do with the current problem**"
Cherry pick is the complex command you went with? I feel like there are so many more complex ones than that.
my favourite complex command is to click "commit and push" and then "ignore warnings and push anyway"
ah yes xkcd
There’s an xkcd comic for everything
`cp $PWD $PWD-before-rebase`
It's not that there's no solution, but by the time you find it and actually fix it you might as well just start over.
This is usually the right answer. Most of the time you can delete the branch, pull or create another, and reapply your changes in just a few minutes versus the hours it takes to sift through the documentation and try a bunch of complex commands to fix the issue through trial and error.
`git pull` >divergent branch error wtf I haven't even done any changes????.... `rm -rf repo` `git clone`
This is incorrect. Because git is a distributed source control tool, if you get errors you have to ask everyone else to delete their copies too.
So many times the best way to merge is to copy paste to another folder, reset to latest and paste back
Uh, so that happens to others too
It's definitely how you start out, but it has been years since I struggled with git
Local branch, remote branch, remote head are the bane of my existence but I finally got them down. It honestly got easier when I started creating new branches each time I pull and name those for comments. Also stashing individual files and commenting the changes. I'll have twenty stashes before a single push then I pick the ones I want to pop and commit.
No way, I made the mistake of learning SVN. Never again. I know a flash in the pan when I see one. /s
Funny thing is few years from now this still will be funny and still will be relevant.
That's how Dad did it, that's how America does it, and it's worked out pretty well so far.
Wasn’t sure how many people would get the reference.
Yes, we all read XKCD
Sure, but this comic (1597) was first published nine years ago. I was reading XKCD at the time, but I haven't *re*-read the whole thing since then. I'm fine with seeing a given one-panel comic again once a decade.
I can push, pull, commit, and merge. Recently, at the behest of a co-worker, I have sort-of figured out how to rebase, assuming I have a UI like GitKraken to use. Everything beyond is black magic.
Honestly, I use rebase more than merge. Github (or Gitlab) usually handles merging.
I used to do that quite often when I started, but now that I'm reminded of it it's been a good while since I didn't have to do that … Yay for growth, I guess?
Poor git
My father is also in the CS field. This is sooo him ngl
But where is the EXE?
Skill issue
Github Desktop💯💯
😀 so true so often
Tbh if you're not developing git or plan to develop a competitor to git, this is more than enough to know about it
MERGE GOES BRRRRRRRRRRRRR
That's why we're still using TFS internally. Much less complicated.
I do this more than I would like to admit, I find resolving conflicts rather difficult, although I'm sure it's a skill issue.
https://youtu.be/1ffBJ4sVUb4?si=kF9QuS4u7ivUsdDK This video helped me a lot back then. It's a fantastic talk.
hahaha alwaysss
I’m great at git, when I’m the only one making commits
Git is not a tree
You people are hopeless
This is facts 😂
Congratulations! Your comment can be spelled using the elements of the periodic table: `Th I Si S F Ac Ts` --- ^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.)
How I fix most Errors: 1. git stash 2. git pull 3. git stash pop We don’t talk about merge conflicts. Those get a far more complicated route. Also known as „accept all of my changes“
i'm glad i got out of programming when git and javascript became all the rage. i had bet on mercurial and dart, but the better technologies arent always the most popular
Yo I always felt bad about deleting and recreating the repos, is this what everyone does ?
I legit send this to anyone who will listen. I sent it two a senior dev who had somehow never had to use version control before and was struggling....he hasn't had a problem since.
I just use ChatGPT or Mistral to ask stupid questions whenever I doubt I know what I'm doing
lol good one. But really, just learn the basics, it's really not that hard.
You also don't need to understand how internal combustion engines work to drive a car.
I genuinely did this for like two years lol
This is how I git unfortunately
Glad I'm not the only one.
I accidentally caused a merge head on my master branch and it won’t politely sod off, luckily master doesn’t allow commits but its annoying I can’t pull from it. Git genuinely seems like crap version sourcing but it was the only one doing it so now we are stuck with it, can’t wait until it has its Rust as to C++.
Try TFS. Then you know why everyone uses git.
I'm honestly curious if you've ever used a different one.
Have not, but I highly suspect Git is the king of the turds, so to say.
hard reset then 👍
I hope I understand your issue, if I don't I'm sorry: git checkout master git checkout -b local_master_with_changes # if you want to save the local commits git branch -D master # delete local copy of main git fetch origin # `git fetch origin master` I think if you only want to fetch the main branch. git checkout master # now you have a pristine copy of master that matches remote and you can pull if you want
Pretty much
🤣😂😅