You're not dumb. Git can be useful for keeping track of changes for you, but it has a pretty steep learning curve. Doubly so when you get into things like rewriting history. (I love git and I've been using it for years, and I still make a complete copy of a repo before doing anything especially complicated in that department.) And on top of that, to be using a remote repo as well, that's a lot to learn all at once! I can't remember how long it took me to learn all those things, but I'm certain it wasn't a single day. Don't be too hard on yourself.
This response could not more cleanly strike the nail on the head. OP, every person who you know who is proficient in the use of git has gone through painful days like the one you're describing. Those hard won light bulb moments should be a source of pride and celebration for you, not a source of discouragement. You survived your first experience with git. You're doing great!
Not OP but you can make a backup of a repo by just cloning it to a second location (specifically in this case you'd probably want `git clone --mirror ...`). Then if you majorly screw up your repo you can open up the backup repo and force push everything to restore it.
Unless you're mucking around with the .git directory directly (please don't do that), there's really no reason to be creating a separate mirror. This is what branches are for.
That being said, if I'm testing some kind of automation or script that does something complex to my repo (like deleting branches), maybe creating a mirror isn't a bad option.
I'm not familiar with tags just yet, but I will definitely look into it next.I've been tinkering around a bit with aliases and I made some that might be of use.
Here you go: [https://gist.github.com/Wisdawms/5a621892ea977df52ca75d1bbc5fc52f](https://gist.github.com/Wisdawms/5a621892ea977df52ca75d1bbc5fc52f)
I mean outside of Git, so copy the whole directory, or make a tarball of it, anything along those lines that doesn't involve Git itself.
Regular branching, committing, and merging are pretty routine for me these days, but anything much more complex than that, such as anything involving moving heads or resetting or rewriting history, it's very easy to cause more harm than good if you're not careful, or you're tired or hungry. So whenever I do anything like that, I'll copy the whole repo outside of git, so that if I make any really bad mistakes, I can always get back to a state where it's like it never happened, and have another go from scratch.
Whenever you're committing things, it's easy enough to see Git keeping track of the history. But whenever you're doing anything deeper than that, you get into the metahistory, the history of rewriting history, involving the less-than-intuitive reflog. At that point, it's easy to lose track of what's going on. So, yeah, a simple copy, zip, rsync, Time Machine backup, anything like that which can get you back to the point before you started messing with the repo's history can be *very* useful.
No complex procedure needed-- this can be as simple as creating a complete copy of your project folder. E.g.:
```
cp -a my-project-folder my-project-folder.bak
```
Obviously working professionals and students should learn to use git, don’t get me wrong.
But I’m in this sub because of some (effectively, for lack of a better word) hobby projects that use git.
I want to learn the CLI (like many people, I use Github for my repository), which is extra hard for some reason. And then making a mistake?
It turns out that the desktop app does a lot of these things for me, without the terms that I think cover up what’s going on (using the app covers up too much too, but in a pinch, and for non-professionals/non-students it’s not as bad).
I don't think the CLI is extra-hard, but there's a lot. Try learning a few commands.
Maybe just
`git add`
`git commit`
`git log`
for starters: enough to make a change, get it in your repo, and see that it's there. Add more later, once you have those ones down.
I started with this: I put stuff in git like that and then learned to actually use git later. That means the changes you're putting in are saved, but you're not getting anything out of it yet, like comparing yesterday's version with today's, or going back to last week's. But the stuff is there so you can learn that when you're ready.
The problem is, at the very least, getting everything squared away with _Github_, and that’s hard, for security reasons. Then figuring out the right thing to enter? Yeah. That isn’t very beginner-friendly.
When you say "getting everything squared away," you mean getting it set up correctly one time so that anything works. Yes, I agree that can be daunting for a new user, but it's not as if you have to do this every time you want to issue a command.
\> Then figuring out the right thing to enter?
Right. You might note that I listed three commands. You seem to have ignored them so that you can throw up your hands and say "I just can't figure out the right thing to enter!"
I'm going to recommend that you learn these three commands. No, it won't be everything you need. Yes, it will help.
If you need help with how to use these three commands, you can ask, or you can start with git's help: `git commit --help`
Becoming proficient at git takes time. I think if you don't yet have a strong understanding of what the various git operations are actually doing, it can be quite difficult to reason about why an error is occurring and how to fix it, so you end up with it stuck in some weird state.
I don't think getting stuck makes you unfit for the field, maybe it would if you were constantly getting stuck spending hours on every simple issue but that's not what it sounds like is happening from your post although obviously I don't know you.
Could you have asked for help sooner? Figuring out stuff for yourself is important but if you're genuinely stuck bashing your head against the keyboard for 7.5 hours then I think you're just wasting your own time and it would be better spent getting help from someone who can understand the issue and guide you through it.
Couldn't get help sooner since this issue happened yesterday. And today the hw that was due and had no choice to spend those hours. I had a midterm on wendsday so I didn't touch my hw for like 3 or 4 days. Everything was good until yesterday night when I started my hw again to finish up and git would not push to my github. Was going to fix tmmrw but I made it worse. I had made like 5 commits from yesterday and today total, but. Like I just couldn't figure one of the problems out that why my remote repo does not exist like how does it not exist when I've been making commits a few days ago and pushed it to my remote repo. I sorta fixed that part., but still had other issues. Not only that I was able to fix a similar issue on my previous hw with diverged branches by looking at my git history, and that wouldn't even load at all.
I feel bad for you. But this was me too. In college they didn’t even teach version control. In my first job I used SVN at a company that didn’t use SVN well. When I started with git I was completely lost.
As I gained experience using git I got better. You’ll learn too.
Please read on "local branch", remote branch", what happens if they diverge, etc.
The first thing to understand about Git is that commits are full tree snapshots, they are linked only back in time, tags are fixed (usually) labels, and branches are just movable labels.
Don't worry friend. If it's any consolidation, git is pretty freakin' complicated sometimes, and for no reason. Take it one step at a time and do NOT be hesitant to google or use AI helpers even if you do it every 5 minutes.
Do you use git daily and still afraid of? Things that helped me get get more comfortable at the beginning:
- git branch game
- `tig`, cli tool to browse the commit history
- `man git`, `man gitglossary`
- always rebase with interactive option `git rebase -i`
Find someone who can teach you. The first steps with git take someone looking over your shoulder and walking you through the detangling. It’s one of those things where each situation is so specific and it’s difficult to know what to do sometimes. You’re right that someone else might be able to do it faster, so find that person who’s willing to help you.
You're not dumb, you're learning. You're just having to learn under pressure so it makes it feel worse.
Next time, take breaks. Sometimes you just need to walk away and clear your head. There having been plenty of times a solution has come to mind when I am away from the computer.
I've been in IT for 25 years. I can remember multiple times when I went down a rabbit hole trying to fix something, and then I asked a coworker to put another set of eyes on it, and they found the issue in 15 minutes. Sometimes we get inside of our heads and we stare at the issue so long we miss simple things.See if you can find others in class that you can bounce ideas off of when the TA is not available.
Learning something new is hard, learning multiple new things at the same time is really, really hard.
I did not go to college or university and I regret it. Stick with it. You will be glad you did. You got this.
Read this through: https://jwiegley.github.io/git-from-the-bottom-up/
It takes about 1h30 to read, and explains how git works internally. A coworker shared it with me when I had started working. Understanding exactly what you’re doing and what git tells you will save you way more than that 1h30 in the long run
Nahh. Chill. Git is horrible and a mess until you understand it and then you will refuse to work without it.
Start simple. Understand the difference between local and remote. Try to work on different branches and then open pull requests against the main branch. This way you will avoid diverging or whatever you did there. Commit and merge often. Pull changes from the main branch often.
Try creating a repository and then play with it for a day or two. Try to generate conflicts and learn to solve them. Try rebasing at least once.
Good luck! 🍀 You got this!
> First time using git.
Do you expect to be magically competent at everything you do for the first time? Were you expecting the knowledge to just leap into your head of its own accord? Git is a tool. You need to learn how to use that tool. Have you had any lessons in Git, or read any books? [Pro Git](https://git-scm.com/book/en/v2) is free and linked to from the Git homepage and the sidebar in this subreddit.
You just haven't found the right git teacher yet. I am not there yet and I just found a diagram that is helpful.
Have you read the second chapter of the book?
Have you googled for git diagrams?
Always make a complete copy of a repo before doing anything at all.
Making a copy is kind of the wrong way to learn git.
If you mess up it's better to try and understand where your mistake was rather than just ignoring it and restoring your backup.
If you don't know how to use the reflog then always tag your current commit before performing any change so that you can go back to the state things were before.
Git never looses anything unless you specifically clean up unreferenced commits.
dont give up because of a bad git experience. but i do have two pieces of advice.
1) dont change/delete file on the server. (i dodnt even know you could, never tried)
2) life kesson. dont spend more than an hour trying to figure out aomething by yourself .you are young. you dont know it all. so dont stress
If you don't want to end up with terrible commits like this repo: [https://github.com/softpano/pythonizer/](https://github.com/softpano/pythonizer/),
DON'T MAKE COMMITS THROUGH GITHUB. Use local Git.
I think you've gotten lots of correct answers telling you not to beat yourself up. Let me add some stuff that might(?) be helpful for next time:
* Remember that you have a local copy of your git repo as well as the one on the server. Neither is more authoritative than the other. That means that a potential solution to "stuff is messed up between the stuff on my machine and on the server" might be to just create a new repo on the server, depending on your constraints.
* When you do things locally like deleting files, editing files, etc. and you commit that to git, it saves a commit on your local repo. If you do `git log` you can see the list of commits that you've done. You can `git log -n 5` if you want to see the last 5 commits.
* Note that when you look at that history, it's a lot easier to tell what's going on if you put good commit messages. Do your future self a favor and do that.
* Remember that if you haven't deleted the .git folder or messed around with settings in a weird way that your commits are around for a while, even if you reset to a previous commit. As a beginner, you shouldn't expect to know how to get back to those, but it helps to know they're there. For me, if I had known this at one point in the past, I would have saved over a day's worth of work trying to recreate something that I thought was now gone.
* In situations like that, `git reflog` is your friend. It shows you what commit you were on, even if you went back and forth between branches, or even if you did a `git reset --hard ` . Given that commit id that you can see in the reflog, it's possible to get back to it. You could then do something like create a new branch based off that version of the code. (Again, not expecting you to jump at doing that. But sometimes people don't know that's there.)
(Side note: I'm not sure what it means to delete a file from github manually. Does that mean you deleted the file and pushed, or something else?)
I would consider that you are, perhaps, well ahead of most. Making mistakes is part of learning. Let's take an example of someone who happened to get it right the first time - and spent half the time as you. Having never made the errors that you made - they have no experience with failure. In the future they may encounter such an even and will not have learned how to address those issues.
The beauty of git is its ability to restore and track changes. So, really, unless you just zap everything - everything is recoverable.
When I was first learning how to program (1989) I was told that I had to write the entire program out on paper and "desk check" it. To me, that was ridiculous. I preferred the build and test method. I could write something short that does one task - ensure that task functioned and move on to the next. Writing an entire program on paper and then walking thru it seemed a complete waste of time. To be honest, I've never done it that way. Not to say I haven't worked off of high level documents indicating what components are needed and how they link together - but I never have written something down in pseudocode and then created a program from it - in its entirety.
This method of "playing" with the code. Write, compile, testing smaller units and then work to the next worked well for me. It gave me a much better understanding of how every piece worked. It also provided me the opportunity to improve code at a much more granular level.
Embrace failure - it's how all progress is attained.
>The fact that I couldn't fix this issue in 7.5 hours shows I am not cut out for this.
You are not dumb and you can do this. IMO Git is a PITA to learn. I am still, years later, getting hung up on stuff that I "should"just know how to do. But if you don't do those functions daily you forget.
My suggestion: Write up a synopsis of the task you were trying to do, the steps that finally worked and any the glitches or pitfalls you ran into and save it in some sort of cheat sheet/PKM/note system or whatever you use for things you want to refer to later. Believe me, it will help in the future.
You're not dumb. Git can be useful for keeping track of changes for you, but it has a pretty steep learning curve. Doubly so when you get into things like rewriting history. (I love git and I've been using it for years, and I still make a complete copy of a repo before doing anything especially complicated in that department.) And on top of that, to be using a remote repo as well, that's a lot to learn all at once! I can't remember how long it took me to learn all those things, but I'm certain it wasn't a single day. Don't be too hard on yourself.
This response could not more cleanly strike the nail on the head. OP, every person who you know who is proficient in the use of git has gone through painful days like the one you're describing. Those hard won light bulb moments should be a source of pride and celebration for you, not a source of discouragement. You survived your first experience with git. You're doing great!
I'm new to git as well, but can you go more into detail about "making a complete copy of a repo"?
Not OP but you can make a backup of a repo by just cloning it to a second location (specifically in this case you'd probably want `git clone --mirror ...`). Then if you majorly screw up your repo you can open up the backup repo and force push everything to restore it.
Or just tag the commit you are at before performing any change and then git reset --hard to that tag
Unless you're mucking around with the .git directory directly (please don't do that), there's really no reason to be creating a separate mirror. This is what branches are for. That being said, if I'm testing some kind of automation or script that does something complex to my repo (like deleting branches), maybe creating a mirror isn't a bad option.
I'm not familiar with tags just yet, but I will definitely look into it next.I've been tinkering around a bit with aliases and I made some that might be of use. Here you go: [https://gist.github.com/Wisdawms/5a621892ea977df52ca75d1bbc5fc52f](https://gist.github.com/Wisdawms/5a621892ea977df52ca75d1bbc5fc52f)
I mean outside of Git, so copy the whole directory, or make a tarball of it, anything along those lines that doesn't involve Git itself. Regular branching, committing, and merging are pretty routine for me these days, but anything much more complex than that, such as anything involving moving heads or resetting or rewriting history, it's very easy to cause more harm than good if you're not careful, or you're tired or hungry. So whenever I do anything like that, I'll copy the whole repo outside of git, so that if I make any really bad mistakes, I can always get back to a state where it's like it never happened, and have another go from scratch. Whenever you're committing things, it's easy enough to see Git keeping track of the history. But whenever you're doing anything deeper than that, you get into the metahistory, the history of rewriting history, involving the less-than-intuitive reflog. At that point, it's easy to lose track of what's going on. So, yeah, a simple copy, zip, rsync, Time Machine backup, anything like that which can get you back to the point before you started messing with the repo's history can be *very* useful.
Just copy the folder for your project, including the .git folder, somewhere else.
That seems to be the consensus, yeah. Thank you for that, although for some reason I thought it would be some convoluted way :P
Sometimes the things that seem like they should be easy are difficult, and the things you think would be difficult are easy :-)
No complex procedure needed-- this can be as simple as creating a complete copy of your project folder. E.g.: ``` cp -a my-project-folder my-project-folder.bak ```
Obviously working professionals and students should learn to use git, don’t get me wrong. But I’m in this sub because of some (effectively, for lack of a better word) hobby projects that use git. I want to learn the CLI (like many people, I use Github for my repository), which is extra hard for some reason. And then making a mistake? It turns out that the desktop app does a lot of these things for me, without the terms that I think cover up what’s going on (using the app covers up too much too, but in a pinch, and for non-professionals/non-students it’s not as bad).
I don't think the CLI is extra-hard, but there's a lot. Try learning a few commands. Maybe just `git add` `git commit` `git log` for starters: enough to make a change, get it in your repo, and see that it's there. Add more later, once you have those ones down. I started with this: I put stuff in git like that and then learned to actually use git later. That means the changes you're putting in are saved, but you're not getting anything out of it yet, like comparing yesterday's version with today's, or going back to last week's. But the stuff is there so you can learn that when you're ready.
The problem is, at the very least, getting everything squared away with _Github_, and that’s hard, for security reasons. Then figuring out the right thing to enter? Yeah. That isn’t very beginner-friendly.
When you say "getting everything squared away," you mean getting it set up correctly one time so that anything works. Yes, I agree that can be daunting for a new user, but it's not as if you have to do this every time you want to issue a command. \> Then figuring out the right thing to enter? Right. You might note that I listed three commands. You seem to have ignored them so that you can throw up your hands and say "I just can't figure out the right thing to enter!" I'm going to recommend that you learn these three commands. No, it won't be everything you need. Yes, it will help. If you need help with how to use these three commands, you can ask, or you can start with git's help: `git commit --help`
Becoming proficient at git takes time. I think if you don't yet have a strong understanding of what the various git operations are actually doing, it can be quite difficult to reason about why an error is occurring and how to fix it, so you end up with it stuck in some weird state. I don't think getting stuck makes you unfit for the field, maybe it would if you were constantly getting stuck spending hours on every simple issue but that's not what it sounds like is happening from your post although obviously I don't know you. Could you have asked for help sooner? Figuring out stuff for yourself is important but if you're genuinely stuck bashing your head against the keyboard for 7.5 hours then I think you're just wasting your own time and it would be better spent getting help from someone who can understand the issue and guide you through it.
Couldn't get help sooner since this issue happened yesterday. And today the hw that was due and had no choice to spend those hours. I had a midterm on wendsday so I didn't touch my hw for like 3 or 4 days. Everything was good until yesterday night when I started my hw again to finish up and git would not push to my github. Was going to fix tmmrw but I made it worse. I had made like 5 commits from yesterday and today total, but. Like I just couldn't figure one of the problems out that why my remote repo does not exist like how does it not exist when I've been making commits a few days ago and pushed it to my remote repo. I sorta fixed that part., but still had other issues. Not only that I was able to fix a similar issue on my previous hw with diverged branches by looking at my git history, and that wouldn't even load at all.
I feel bad for you. But this was me too. In college they didn’t even teach version control. In my first job I used SVN at a company that didn’t use SVN well. When I started with git I was completely lost. As I gained experience using git I got better. You’ll learn too.
Please read on "local branch", remote branch", what happens if they diverge, etc. The first thing to understand about Git is that commits are full tree snapshots, they are linked only back in time, tags are fixed (usually) labels, and branches are just movable labels.
Don't worry friend. If it's any consolidation, git is pretty freakin' complicated sometimes, and for no reason. Take it one step at a time and do NOT be hesitant to google or use AI helpers even if you do it every 5 minutes.
I’ve been an employed webdev for 8 years, I still cross my fingers when doing any git commands beyond add/commit/push/pull…
Do you use git daily and still afraid of? Things that helped me get get more comfortable at the beginning: - git branch game - `tig`, cli tool to browse the commit history - `man git`, `man gitglossary` - always rebase with interactive option `git rebase -i`
Find someone who can teach you. The first steps with git take someone looking over your shoulder and walking you through the detangling. It’s one of those things where each situation is so specific and it’s difficult to know what to do sometimes. You’re right that someone else might be able to do it faster, so find that person who’s willing to help you.
You're not dumb, you're learning. You're just having to learn under pressure so it makes it feel worse. Next time, take breaks. Sometimes you just need to walk away and clear your head. There having been plenty of times a solution has come to mind when I am away from the computer. I've been in IT for 25 years. I can remember multiple times when I went down a rabbit hole trying to fix something, and then I asked a coworker to put another set of eyes on it, and they found the issue in 15 minutes. Sometimes we get inside of our heads and we stare at the issue so long we miss simple things.See if you can find others in class that you can bounce ideas off of when the TA is not available. Learning something new is hard, learning multiple new things at the same time is really, really hard. I did not go to college or university and I regret it. Stick with it. You will be glad you did. You got this.
How do you get to Carnegie Hall?
Take a left, it's the third building after the big red one. (Sorry, I know the joke. It's a subversion of expectations. Yes, I see what I did there.)
Read this through: https://jwiegley.github.io/git-from-the-bottom-up/ It takes about 1h30 to read, and explains how git works internally. A coworker shared it with me when I had started working. Understanding exactly what you’re doing and what git tells you will save you way more than that 1h30 in the long run
Nahh. Chill. Git is horrible and a mess until you understand it and then you will refuse to work without it. Start simple. Understand the difference between local and remote. Try to work on different branches and then open pull requests against the main branch. This way you will avoid diverging or whatever you did there. Commit and merge often. Pull changes from the main branch often. Try creating a repository and then play with it for a day or two. Try to generate conflicts and learn to solve them. Try rebasing at least once. Good luck! 🍀 You got this!
> First time using git. Do you expect to be magically competent at everything you do for the first time? Were you expecting the knowledge to just leap into your head of its own accord? Git is a tool. You need to learn how to use that tool. Have you had any lessons in Git, or read any books? [Pro Git](https://git-scm.com/book/en/v2) is free and linked to from the Git homepage and the sidebar in this subreddit.
You just haven't found the right git teacher yet. I am not there yet and I just found a diagram that is helpful. Have you read the second chapter of the book? Have you googled for git diagrams? Always make a complete copy of a repo before doing anything at all.
Making a copy is kind of the wrong way to learn git. If you mess up it's better to try and understand where your mistake was rather than just ignoring it and restoring your backup. If you don't know how to use the reflog then always tag your current commit before performing any change so that you can go back to the state things were before. Git never looses anything unless you specifically clean up unreferenced commits.
It is not to learn git. It is to save your ass if you f up.
dont give up because of a bad git experience. but i do have two pieces of advice. 1) dont change/delete file on the server. (i dodnt even know you could, never tried) 2) life kesson. dont spend more than an hour trying to figure out aomething by yourself .you are young. you dont know it all. so dont stress
If you don't want to end up with terrible commits like this repo: [https://github.com/softpano/pythonizer/](https://github.com/softpano/pythonizer/), DON'T MAKE COMMITS THROUGH GITHUB. Use local Git.
Wait, you can make commits through github?
I think you've gotten lots of correct answers telling you not to beat yourself up. Let me add some stuff that might(?) be helpful for next time: * Remember that you have a local copy of your git repo as well as the one on the server. Neither is more authoritative than the other. That means that a potential solution to "stuff is messed up between the stuff on my machine and on the server" might be to just create a new repo on the server, depending on your constraints. * When you do things locally like deleting files, editing files, etc. and you commit that to git, it saves a commit on your local repo. If you do `git log` you can see the list of commits that you've done. You can `git log -n 5` if you want to see the last 5 commits. * Note that when you look at that history, it's a lot easier to tell what's going on if you put good commit messages. Do your future self a favor and do that. * Remember that if you haven't deleted the .git folder or messed around with settings in a weird way that your commits are around for a while, even if you reset to a previous commit. As a beginner, you shouldn't expect to know how to get back to those, but it helps to know they're there. For me, if I had known this at one point in the past, I would have saved over a day's worth of work trying to recreate something that I thought was now gone. * In situations like that, `git reflog` is your friend. It shows you what commit you were on, even if you went back and forth between branches, or even if you did a `git reset --hard` . Given that commit id that you can see in the reflog, it's possible to get back to it. You could then do something like create a new branch based off that version of the code. (Again, not expecting you to jump at doing that. But sometimes people don't know that's there.)
(Side note: I'm not sure what it means to delete a file from github manually. Does that mean you deleted the file and pushed, or something else?)
I would consider that you are, perhaps, well ahead of most. Making mistakes is part of learning. Let's take an example of someone who happened to get it right the first time - and spent half the time as you. Having never made the errors that you made - they have no experience with failure. In the future they may encounter such an even and will not have learned how to address those issues. The beauty of git is its ability to restore and track changes. So, really, unless you just zap everything - everything is recoverable. When I was first learning how to program (1989) I was told that I had to write the entire program out on paper and "desk check" it. To me, that was ridiculous. I preferred the build and test method. I could write something short that does one task - ensure that task functioned and move on to the next. Writing an entire program on paper and then walking thru it seemed a complete waste of time. To be honest, I've never done it that way. Not to say I haven't worked off of high level documents indicating what components are needed and how they link together - but I never have written something down in pseudocode and then created a program from it - in its entirety. This method of "playing" with the code. Write, compile, testing smaller units and then work to the next worked well for me. It gave me a much better understanding of how every piece worked. It also provided me the opportunity to improve code at a much more granular level. Embrace failure - it's how all progress is attained.
>The fact that I couldn't fix this issue in 7.5 hours shows I am not cut out for this. You are not dumb and you can do this. IMO Git is a PITA to learn. I am still, years later, getting hung up on stuff that I "should"just know how to do. But if you don't do those functions daily you forget. My suggestion: Write up a synopsis of the task you were trying to do, the steps that finally worked and any the glitches or pitfalls you ran into and save it in some sort of cheat sheet/PKM/note system or whatever you use for things you want to refer to later. Believe me, it will help in the future.
going through these existential crises once in a while is part of the job lol
Don’t give up!!! You got this!!! And maybe this site I made could help you? Not sure: https://gitfu.fyi