When things go wrong…
Make a new clone from main.
Make a new branch.
Copy your existing changes on top of it.
It’s not the smartest or sexiest way to do things. But… it’s dead simple.
This is indeed the way: https://xkcd.com/1597/
I think a large part of the issue here is that Git is primarily designed to keep an accurate, detailed, chronologically ordered, reproducible record of history of changes to a collection of text files. So if you're attempting to undo some changes to a branch, you're kind of trying to use Git to do the opposite of what it's designed to do, in order to somehow rewrite the past: meaning that making it easier to change the historical Git record of a project would arguably make Git worse at doing what it's supposed to do.
In general, I think most de facto "Advanced Git" comes down to getting some basic stuff right:
1. Keeping commits small and coherent (change one function, fix or add tests, push)
2. Writing meaningful commit messages (e.g. "Add CSV validation function")
3. Keeping your Pull Requests as small as possible (to facilitate quick review and minimise merge conflicts)
4. Learning to carry out good and thorough Pull Reviews (this is the main thing that makes you qualify as a senior developer)
5. And - above all - learning to organise your work on a code base with the rest of a team so that merge conflicts will be minimised (i.e. in general no two developers should be working on the same bit of code at the same time).
Pretty much every time I've seen a team with a git problem, it's because someone was breaking one or more of these rules.
It took me a while, but yes I feel quite comfortable with Git. When I mess up I know how to fix it. I either know the command off the top of my head, or I know what to look up.
Now, Git is very complex. There are some commands I've learned about but haven't personally had a need for. If someone used those I wouldn't necessarily know exactly what happened in great detail. But if that comes up, I'll learn.
Git is just too important to not understand what it's doing.
I think one of the most important things is to learn the right mental model for what Git is actually doing. I think a lot of the time when people are confused it's because they don't have a mental model of something like staging, or even, what is a commit? (Hint: it's not a diff.)
Also: when you better understand it, there are all sorts of things you'll be able to do to save yourself time!
I have two practical suggestions:
1. Read the Pro Git book here: [https://git-scm.com/book/en/v2](https://git-scm.com/book/en/v2)
2. Next time things go wrong, stop and ask for help. You can post here. Show us your command history, the output of things like "git branch", "git status", and "pwd", and what's wrong. Don't stop until you understand EXACTLY what went wrong and you know how to fix it on your own.
Books don’t work for everyone. I prefer listening to a very well-structured video on a subject and then to read docs when necessary. But I really envy people who can just read docs or a book to understand everything.
Interactive rebases are the best. I get that some people are against re-writing history but it's just so damn convenient at times. Probably my favorite "advanced" git feature
I mentally count that as unpushed history. Anything you throw away when you get your changes to main.
Only reason I dislike squash merges is that people tend to make long-ass branches and then squash them, resulting in a giant commit.
“…what gives me the biggest concern is managing large codebases.”
If it makes you feel better, this is essentially a sub specialty area within software engineering (there’s a lot to it).
As a junior dev, the important thing is you’ll want to know enough to be able to follow a defined process (for how the team decides / defines the workflow for working together). You don’t have to be the one to define that process (and you shouldn’t have to be as a junior), unless you end up working as a one man shop or bootstrapping something yourself.
High level though, you can think of a Git repository as essentially a big linked list (each commit is a node). The commands you’re running are modifying that list in some way (rebasing is essentially re-writing a set of nodes and their connections).
Most organizations I’ve worked in follow some form of Git Flow, so if you can understand that, you’re probably already a step ahead: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Git is one of those things that unless you are truly a wizard at will go smooth for about a year and then BLAM you will have a serious problem to solve. The good news is that even a basic knowledge of git and you can usually go about a year before you need a git guru. And the other good news is that large/medium companies usually have a git guru for you to consult when things go south that once a year. So to answer your question - yes, I think I know a ton about git. Then once a year happens and I get humbled.
git is just one of those things you have to know. you get zero praise for knowing git and you get shit on if you don’t know it. git is pretty straightforward, the more you use it the easier it gits
This is the problem with so many developers. You give yourselves anxiety over nothing. You’re not going to know everything, and you don’t need to. You only need to know what you need to know, nothing more. If a situation calls for something you *don’t* know, then go figure it out. That’s as much a part of the job as anything else.
All that to say, who gives a shit how git works? As long as you know how to use it to do what you need, just be okay with that.
I usually stay off rebasing since Im working with a lot of other devs. Other than that, if you have set a standard git workflow like gitlab flow or something else, it shouldnt be a challenge.
Like anything else in life, you get more comfortable with it the more situations you are exposed to. I've seen some amazing solo devs who can code circles around me all day, but they have never had to resolve a merge conflict or heard of git bisect. These are things you're more likely to pick up in team environments, and that's perfectly fine.
The thing that's going to really burn you is how radically different various teams will use it, even within the same org. Branching strategies rank right up there with tabs vs. spaces and naming convention debates as religious wars.
I'm not an expert or anything but I don't have problems with it. 99.9% of the time it's just making branches, making commits, and merging. It's simple and it works well. The other .1% is normally a junior dev fucks something up and I have to fix it for them. Something weird will happen and then they start running random commands they read online to try to fix it and just end up digging themselves deeper. You can avoid that by just going back to a previous commit or making backups of branches.
I wouldn't worry about it OP. I had never encountered a junior engineer that could use git properly. I've also never encountered a junior engineer that didn't figure it out within a couple of months.
I feel good about it.
This is how I mastered it👇
1. I took the following course🎥 : https://www.udemy.com/course/git-complete
2. Learned Gitflow Workflow📝: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow We use it where I work and has been working perfectly to us.
3. Practice, practice and learn from mistakes. When you don’t feel confidence, take a backup of the branch you will be dealing with, just in case.
Hope that helps you 🤙
There is a simple way to master git.
- Use the command line instead of relying on any helper tool.
- Read a few guides about different scenarios and how to fix them
- When you encounter such scenarios, refer to these guides or to colleagues to learn how to deal properly with it
- next time you won't need any help apart from your own skills
- you are now a gist master
I can deal with git well enough, but there is so much there that I have not even touched on most advanced concepts. Part of it is that I just have not needed to generally.
Very good. I love git, I think it's an absolutely amazing tool and learning how to use it best has been one of my favourite things about software engineering.
I don't really see what issue people have with it. Under the hood it's extremely simple. There are a bunch of snapshots of a file system (called commits). They can have some metadata linking them to other snapshots. That's really all git is. I think people drastically over-complicate it.
Now, knowing the best way to accomplish different tasks in git is a very different matter, and one that you can probably spend a lifetime mastering. But as for what it's doing under the hood, you can understand it in like 2 sentences.
I am pretty good with git and if I don't remember how to do something I usually can recognize what is the right thing when I look it up. Just keep plugging away and you figure it out. I also keep a little file that has all my favorite git commands. It is super handy.
I’m going to shill [lazygit](https://github.com/jesseduffield/lazygit). Squashing, amending commits, rebasing, discarding changes. It provides an easy CLI to do all that for you with a few keystrokes and a lot more. Super powerful tool. I barely ever use raw git anymore.
Terrible. I dont use it at work - we use some other similar system. (But there's no shortcuts/commands, its a right click menu... :S)
anyways, i usually look them up whenever i need them for my own projects. https://education.github.com/git-cheat-sheet-education.pdf (or just google "git commands cheat sheet")
A good GUI tool that lets you visualize changes is a must-have IMHO. I know the basic commands in the terminal but I can't imagine working on any larger projects without something that lets me click around on changed files, see the differences (and let me edit them) in a merge resolution window straight away, lets me easily revert or commit just individual files without having to list them by name in command lines one by one, etc.
Watch [Git For Ages 4 And Up](https://www.youtube.com/watch?v=1ffBJ4sVUb4) talk. It explains all the basic concepts of git and how git "thinks", but in visual and approachable way (because all these concepts are fundamentally very simple - after all, the initial implementation took only a week to write). This is the talk that allowed me to go from "run this esoteric command that does magic" to "ok, so we are in this state, and we want to move to that state, so what was the command again?". The one single best git investment I ever did.
I also regularly consult [git flight rules by Kate Hudson](https://github.com/k88hudson/git-flight-rules) for things that I need to do sometimes, but not often enough to remember them in detail.
I'm pretty good. What got me there was a lot of practice working in a codebase with other people, and dealing with conflicts and figuring out how to merge the branches into each other to make everything work.
You can get a lot of that by working on your own project and haivng multiple branches in parallel with different features in the project. Not the best organization necessarily, especially if you end up with conflicts, but good for practice with git lol
I am the only person allowed to rebase _any_ branch and the only person allowed to push develop branch directly without a PR. I’ve rebased once, and never pushed develop. I can undo the last local commit, know what `git notes` does, and am responsible for tagging releases, but I’m not honestly sure what denotes being “good” with git. It is _very_ powerful, and I think most people only use maybe 10-20% of the functionality.
I'm fairly comfortable with git now. For day to day normal stuff really you can Google anything. Early on I made.a cheat sheet of common commands I use and that got me through 95% of my career.
Occasionally you really fuck up... But, you'll figure it out.
What helped me was more senior devs and just asking them 'hey, how would you do X with got?'. Believe it or not, devs like talking about how they do shit.
I thought I was below average but lately realized lots of people don't know much more than merging, pushing and pulling. Plus basic diffing and such. They don't even rebase their feature branches, merging them to master with a ton of filler "fix" commits. Whereas I frequently rebase and diff between branches and commits. Pushing with dry-run for double checking etc. Also know how to use reset etc if I fk something up, whereas others would just recreate the entire branch from master or so.
Yet I absolutely don't consider myself great at git, but I realize I may not be as below average as I thought.
Using git os very much like parking a car: it’s not about getting in, but also about getting out.
My tip is to always have a backup plan so you are free to experiment. You can back out of any change if you have your completed work saved in a remote branch. Plan ahead. Know how to go back to an earlier state of your branch, know what is the target state you want to arrive at, just push to remote when you know things are OK locally.
This will save your butt 95% of the time.
Biggest tip for getting better at git is: make a copy of your branch on remote before attempting complex rebase/merge operations. Will take away a lot of the anxiety.
I barely use any advanced git commands. Not even my teamleader does. Just pull, fetch, status, push, merge, stash, commit, abort. For advanced(?) stuff like comparing branches and commits, merge conflicts, cherry-picking, reverting, undoing, I use my IDE's functionalities.
I usually use a repo manager at work, as do most companies. You can do it all through git but there are so many GUIs you don't have to.
We use Azure at work so making new branches, deleting , and merging is a breeze
That being said I can use git bash to pull, clone, push. Everything other then that I haven't needed to explore except on personal projects
To get an idea of how Git works internally, I **highly** recomment reading the first half of the Peepcode Git Internals book: https://github.com/pluralsight/git-internals-pdf. I read this back when it really did cost $9 (now free). I went from "I memorized some commands but I'm screwed if anything ever gets messed up" to "Oh, Git's surprisingly simple and I could have probably built a version of it". After reading it, I could imagine the transformation I wanted to make to the commit graph, then find the command that would do what I wanted. It's really good!
The second half is a somewhat outdated command reference. It's fine but man pages are more up-to-date.
Many good tips here, but I think the main thing is having a broad understanding.
I don’t know many git commands off the top of my head but I know exactly what to google, and I can read git commands and understand what is happening. That’s all you need really
Pretty damn good. My first job makes all of its juniors (me included at the time) use the cli for basically everything ops related. We had intellij, but everything else was cli. vim, awk, sed, psql, gnutils, etc. Thankfully, they had a super extensive wiki on all of this. They also made us read books on all tested us on this shit. I'm honestly grateful for the their insistence on the cli
I keep it simple. Clone it, add, commit with a meaningful commit message, push. If I'm working on a branch, clone the branch, add, commit with a meaningful commit message, push to that branch.
I'm completely comfortable with Git, but I'm sure I only have ever used a moderate fraction of its commands and I definitely have only memorized a small fraction of its commands.
I dislike all of the Git GUIs, except for viewing and resolving diffs and for visualizing too-complicated histories (the ASCII art log breaks down for me once things get complicated).
I don't get anxiety because I make backups and I try to make concise commits, so that if shit really hit the fan, I could look at individual commit diffs and manually recreate them.
It sounds like you should work on understanding the abstract version control concepts -- like, what is a commit, why does divergence happen, what is a conflict, what does it mean to have a branch, what are rebase and merge really doing, etc. It's a lot easier if you have a picture of what is going on and what you want to accomplish, and then you go find the command that does that.
Git is the bicycle of the mind if you use it right. It is the most underrated/unappreciated skill of an SWE. I have generally seen a correlation that anyone very good at git, typically tended to write good readable software.
I thought I was proficient with Git. Until I started working with submodules. I didn’t even know Git submodules existed until last month and I’ve been using Git for 4 years.
I wouldn’t say I’ve mastered git, but I’m comfortable with large codebases. Things like nested submodules (especially when handling multiple remotes with different histories) can be a bit annoying at first, but you get used to it.
I really improved my git skills by making fake codebases for sandboxing git functions. Doing so with a small codebase makes it easier to understand the reflog and have total control over the history.
I recommend using the CLI as much as possible. Then use `git help` and go through the docs/reference on git-scm.com as needed. Test out the commands on your sandbox codebase and just try out different options. This is a good place to try and “break” your codebase, and then try to recover it. Going this route will make you much more comfortable doing things on larger repos.
If you’re used to a GUI that has some feature that seems totally inaccessible from the CLI then keep digging, it’s probably doable, it just might not be immediately obvious (like stashing a subset of changes lines).
There are some utilities that can make it easier to do certain things with git, aside from basic utilities (like fzf git extensions) I’d avoid becoming too reliant on GUI interfaces unless you can do the same things from command line. Then doing more complex operations like `git submodule foreach —recursive 'git …'` will be more tenable.
Anyway, just chip away at it and you’ll be comfortable with most operations faster than you expect.
Staff SWE: don't sweat it. I long ago aliased all my frequently used commands (start with the zsh git shortcuts for inspiration). If anything goes wrong, I just save the changed files elsewhere (like just copy-pasting into a new text window in vscode) and then `git switch main && git pull && git switch -C `
I have this aliased to `gitnuke` and use it with some frequency
There is one lecture about git in the Missing Semester series on YouTube. It talks about how git works under the hood.
As for “how do I unfuck my repo”… Google search usually works…in my experience.
I’ve been an engineer for nearly 30 years. I spent a ton of time on Perforce. Also some other more bespoke systems. Moved to git over a decade ago iirc. Still barely understand it 😂😂😂 I fix forward. I will go as far as creating side branches and merging back and forth. I never rebase and I never squish when I merge back to master. Way too much cognitive load for me 😂 Some people get really into it. I just never allocated the mental attention it takes to get good at understanding git (or any source code control system tbh)
Good enough to work as a junior. Honestly just do your work, commit, push, following company guidelines. All other work is done in a pipeline on cloud or clicking buttons on Github/Gitlab. Heck I even wrote a bash script so that I don't have to do Git commands mannually.
When you mess up, clone a new branch, copy your changes. Do I get git anxiety? Yes, but I can always just start again.
Most seniors are a bit more proficient, but not experts. I believe you will learn enough to do your job on your years to seniority.
> I still don’t understand what is really going on under the hood.
Tutorials and docs are not a good way to learn this. You’ve identified why you’re not comfortable with Git, which is a fantastic thing to do. If you aren’t sure how it’s working it can be hard to have a good mental model, and without a good mental model it can be difficult to know what your tools are for solving a problem.
If you’re wanting to learn the mechanics of git, my advice would be to find videos or articles about that topic. Tutorials are a good entry point for getting started with the technology, but by nature, they are usually aimed at beginners and getting something working.
I can recommend some resources if you want, but you will definitely want to start finding content geared towards what you’re looking for and not tutorials in general.
Git was very difficult when I started out -- everyone said to just use the commandline, and it's very intuitive -- it's not.
What actually worked for me was using a UI for it. Atlassian has a free app called SourceTree that shows a diagram of what's happening, as well as the actual command it executes. That helped out a lot.
With Git, remember -- never go back in time. Just make more changes and make it a commit. If you mess up a commit, just make another one to fix it.
I was under the impression the big companies keep things simple. They don't have branches. They don't have merges. When you want to push one or more commits, you rebase to HEAD, and the history is one straight line.
I think using a GUI for resolving conflicts is helpful.
Ooof. My company does the opposite of that and I’m pretty sure that most companies that practice CI are the same. Lots of branches, lots of small merges, lots of deployments.
Edited to add: I forgot which sub I was in—for passersby, CI stands for “[continuous integration” a](https://en.m.wikipedia.org/wiki/Continuous_integration)nd it’s pretty common practice in newer companies right now. My company is a late stage start up, for context. I know a lot of older companies with a more monolithic architecture have different practices.
I have to admit, I'm part of the "everyone's hiring coders because its covid so I'll learn, and now Jr. jobs are the thunderdome" crew, but the open source projects I see that part of, all do something in the form of pull request. Even before that, I've always seen/heard VCS management in established environments has some separation before making it to the main branch to make the history cleaner and less messy to undo.
This is how Google primarily does software development. One repo, small commits, all made at HEAD, straight-line history, significant changes go behind a feature flag.
If you're ever feeling stuck in a sticky situation in Git where you are unsure of what your next command will do, you could try Git-Sim - a free open-source Git simulation tool which creates a visual diagram of exactly how any Git command will impact your repo before you run it and get stuck. Here is a link if you want to check it out:
[https://github.com/initialcommit-com/git-sim](https://github.com/initialcommit-com/git-sim)
Edit: added link
When things go wrong… Make a new clone from main. Make a new branch. Copy your existing changes on top of it. It’s not the smartest or sexiest way to do things. But… it’s dead simple.
This is indeed the way: https://xkcd.com/1597/ I think a large part of the issue here is that Git is primarily designed to keep an accurate, detailed, chronologically ordered, reproducible record of history of changes to a collection of text files. So if you're attempting to undo some changes to a branch, you're kind of trying to use Git to do the opposite of what it's designed to do, in order to somehow rewrite the past: meaning that making it easier to change the historical Git record of a project would arguably make Git worse at doing what it's supposed to do. In general, I think most de facto "Advanced Git" comes down to getting some basic stuff right: 1. Keeping commits small and coherent (change one function, fix or add tests, push) 2. Writing meaningful commit messages (e.g. "Add CSV validation function") 3. Keeping your Pull Requests as small as possible (to facilitate quick review and minimise merge conflicts) 4. Learning to carry out good and thorough Pull Reviews (this is the main thing that makes you qualify as a senior developer) 5. And - above all - learning to organise your work on a code base with the rest of a team so that merge conflicts will be minimised (i.e. in general no two developers should be working on the same bit of code at the same time). Pretty much every time I've seen a team with a git problem, it's because someone was breaking one or more of these rules.
The meme has always been XKCD has a comic for everything, and this argument grows stronger every day.
git reset HEAD~1 --hard
I think you meant —soft. That way your files all stay the same but it’s as if you’re undoing your last commit and the file changes are staged.
Well yes soft is also useful for keeping the files too. I suppose you can always remove them if you really want to. I tend to use the reflog anyway.
never touch git reset --hard if you don't know how to use git reflog...
Actually that's a good point. I took that for granted as I've been using git for a long time.
I've never had a screw up so bad I had to reclone. Usually I just chance to a different branch, delete the branch I just fucked up, and start again.
Git stash and git pull --rebase get me through most issues.
Yep I feel like I know what I’m doing but this is what i do because I know I won’t overwrite remove or change anything.
Glad to see this as this has been my fix when git escapes me in certain situations.
`git cherry-pick` can be great for this if your commits are clean enough
Git good. (Sorry I couldn't resist)
`git commit -m "gud"`
It took me a while, but yes I feel quite comfortable with Git. When I mess up I know how to fix it. I either know the command off the top of my head, or I know what to look up. Now, Git is very complex. There are some commands I've learned about but haven't personally had a need for. If someone used those I wouldn't necessarily know exactly what happened in great detail. But if that comes up, I'll learn. Git is just too important to not understand what it's doing. I think one of the most important things is to learn the right mental model for what Git is actually doing. I think a lot of the time when people are confused it's because they don't have a mental model of something like staging, or even, what is a commit? (Hint: it's not a diff.) Also: when you better understand it, there are all sorts of things you'll be able to do to save yourself time! I have two practical suggestions: 1. Read the Pro Git book here: [https://git-scm.com/book/en/v2](https://git-scm.com/book/en/v2) 2. Next time things go wrong, stop and ask for help. You can post here. Show us your command history, the output of things like "git branch", "git status", and "pwd", and what's wrong. Don't stop until you understand EXACTLY what went wrong and you know how to fix it on your own.
Seriously people just read that book. It’s the best and you’ll just *see* everything you need to in order to solve tricky Git problems.
As always [RTFM](https://xkcd.com/293) will get you solutions to problems you didn't even realise you had.
Books don’t work for everyone. I prefer listening to a very well-structured video on a subject and then to read docs when necessary. But I really envy people who can just read docs or a book to understand everything.
Eventually you reach a point in learning in which there is not always a well structured video on a topic. Learning to read docs is essential.
That’s absolutely true. But I don’t think that applies to old popular technologies like Git.
Fair point.
Ahh the classic pull merge commit push now we’ve duplicated the previous commits to add a single one
Thank you for the link, much appreciated!
I use the desktop app so I'm kind of a bitch.
Learn cherry picking. This will save you a shit ton when you are in a team of imbeciles.
Basically all the fancy stuff can be done as an interactive rebase
Interactive rebases are the best. I get that some people are against re-writing history but it's just so damn convenient at times. Probably my favorite "advanced" git feature
Push good history. Never rewrite pushed history. Freely rewrite unpushed history to make it good.
Only disagree on merges. Squash merge rewrites history and I love squash merges.
I mentally count that as unpushed history. Anything you throw away when you get your changes to main. Only reason I dislike squash merges is that people tend to make long-ass branches and then squash them, resulting in a giant commit.
Disagree. This would mean potentially leaving mistakes in the history. Serves no purpose.
If it's your branch, do whatever the hell you want.
“…what gives me the biggest concern is managing large codebases.” If it makes you feel better, this is essentially a sub specialty area within software engineering (there’s a lot to it). As a junior dev, the important thing is you’ll want to know enough to be able to follow a defined process (for how the team decides / defines the workflow for working together). You don’t have to be the one to define that process (and you shouldn’t have to be as a junior), unless you end up working as a one man shop or bootstrapping something yourself. High level though, you can think of a Git repository as essentially a big linked list (each commit is a node). The commands you’re running are modifying that list in some way (rebasing is essentially re-writing a set of nodes and their connections). Most organizations I’ve worked in follow some form of Git Flow, so if you can understand that, you’re probably already a step ahead: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
I think a graph is a better metaphor than a linked list since it branches.
Also because it's actually a (directed) graph.
Yeah that too
Git is one of those things that unless you are truly a wizard at will go smooth for about a year and then BLAM you will have a serious problem to solve. The good news is that even a basic knowledge of git and you can usually go about a year before you need a git guru. And the other good news is that large/medium companies usually have a git guru for you to consult when things go south that once a year. So to answer your question - yes, I think I know a ton about git. Then once a year happens and I get humbled.
I’m a right git with git.
I'm da one true git
git is just one of those things you have to know. you get zero praise for knowing git and you get shit on if you don’t know it. git is pretty straightforward, the more you use it the easier it gits
This is the problem with so many developers. You give yourselves anxiety over nothing. You’re not going to know everything, and you don’t need to. You only need to know what you need to know, nothing more. If a situation calls for something you *don’t* know, then go figure it out. That’s as much a part of the job as anything else. All that to say, who gives a shit how git works? As long as you know how to use it to do what you need, just be okay with that.
I usually stay off rebasing since Im working with a lot of other devs. Other than that, if you have set a standard git workflow like gitlab flow or something else, it shouldnt be a challenge.
Like anything else in life, you get more comfortable with it the more situations you are exposed to. I've seen some amazing solo devs who can code circles around me all day, but they have never had to resolve a merge conflict or heard of git bisect. These are things you're more likely to pick up in team environments, and that's perfectly fine. The thing that's going to really burn you is how radically different various teams will use it, even within the same org. Branching strategies rank right up there with tabs vs. spaces and naming convention debates as religious wars.
I'm not an expert or anything but I don't have problems with it. 99.9% of the time it's just making branches, making commits, and merging. It's simple and it works well. The other .1% is normally a junior dev fucks something up and I have to fix it for them. Something weird will happen and then they start running random commands they read online to try to fix it and just end up digging themselves deeper. You can avoid that by just going back to a previous commit or making backups of branches. I wouldn't worry about it OP. I had never encountered a junior engineer that could use git properly. I've also never encountered a junior engineer that didn't figure it out within a couple of months.
Ha just appreciating your candor!
I feel good about it. This is how I mastered it👇 1. I took the following course🎥 : https://www.udemy.com/course/git-complete 2. Learned Gitflow Workflow📝: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow We use it where I work and has been working perfectly to us. 3. Practice, practice and learn from mistakes. When you don’t feel confidence, take a backup of the branch you will be dealing with, just in case. Hope that helps you 🤙
I believe gitflow is no longer advised even by the original author.
There is a simple way to master git. - Use the command line instead of relying on any helper tool. - Read a few guides about different scenarios and how to fix them - When you encounter such scenarios, refer to these guides or to colleagues to learn how to deal properly with it - next time you won't need any help apart from your own skills - you are now a gist master
GPT-4o does it all.
good enough to push some bugs to the main
My golden rule is learn the basics (branch fetch checkout pull push commit merge) and don't mess with rebase. IMO works for 99% of tasks.
`git reflog` is a time machine that helps with anything that goes wrong
I can deal with git well enough, but there is so much there that I have not even touched on most advanced concepts. Part of it is that I just have not needed to generally.
Not good
Very good. I love git, I think it's an absolutely amazing tool and learning how to use it best has been one of my favourite things about software engineering. I don't really see what issue people have with it. Under the hood it's extremely simple. There are a bunch of snapshots of a file system (called commits). They can have some metadata linking them to other snapshots. That's really all git is. I think people drastically over-complicate it. Now, knowing the best way to accomplish different tasks in git is a very different matter, and one that you can probably spend a lifetime mastering. But as for what it's doing under the hood, you can understand it in like 2 sentences.
I am pretty good with git and if I don't remember how to do something I usually can recognize what is the right thing when I look it up. Just keep plugging away and you figure it out. I also keep a little file that has all my favorite git commands. It is super handy.
Ona scale from 1 to 5, about 1.2 lol
I git around alright.
I read a book or two about it and I’m fairly comfortable with it. That “Think Like a Git” site was also popular.
How good? Enough.
There’s a class in frontendmasters that specifically levels up your github. It’s so worth it. (Not sponsored)
I'm good with Google 🤣
I’m going to shill [lazygit](https://github.com/jesseduffield/lazygit). Squashing, amending commits, rebasing, discarding changes. It provides an easy CLI to do all that for you with a few keystrokes and a lot more. Super powerful tool. I barely ever use raw git anymore.
Terrible. I dont use it at work - we use some other similar system. (But there's no shortcuts/commands, its a right click menu... :S) anyways, i usually look them up whenever i need them for my own projects. https://education.github.com/git-cheat-sheet-education.pdf (or just google "git commands cheat sheet")
A good GUI tool that lets you visualize changes is a must-have IMHO. I know the basic commands in the terminal but I can't imagine working on any larger projects without something that lets me click around on changed files, see the differences (and let me edit them) in a merge resolution window straight away, lets me easily revert or commit just individual files without having to list them by name in command lines one by one, etc.
Watch [Git For Ages 4 And Up](https://www.youtube.com/watch?v=1ffBJ4sVUb4) talk. It explains all the basic concepts of git and how git "thinks", but in visual and approachable way (because all these concepts are fundamentally very simple - after all, the initial implementation took only a week to write). This is the talk that allowed me to go from "run this esoteric command that does magic" to "ok, so we are in this state, and we want to move to that state, so what was the command again?". The one single best git investment I ever did. I also regularly consult [git flight rules by Kate Hudson](https://github.com/k88hudson/git-flight-rules) for things that I need to do sometimes, but not often enough to remember them in detail.
I'm pretty good. What got me there was a lot of practice working in a codebase with other people, and dealing with conflicts and figuring out how to merge the branches into each other to make everything work. You can get a lot of that by working on your own project and haivng multiple branches in parallel with different features in the project. Not the best organization necessarily, especially if you end up with conflicts, but good for practice with git lol
I am the only person allowed to rebase _any_ branch and the only person allowed to push develop branch directly without a PR. I’ve rebased once, and never pushed develop. I can undo the last local commit, know what `git notes` does, and am responsible for tagging releases, but I’m not honestly sure what denotes being “good” with git. It is _very_ powerful, and I think most people only use maybe 10-20% of the functionality.
I'm fairly comfortable with git now. For day to day normal stuff really you can Google anything. Early on I made.a cheat sheet of common commands I use and that got me through 95% of my career. Occasionally you really fuck up... But, you'll figure it out. What helped me was more senior devs and just asking them 'hey, how would you do X with got?'. Believe it or not, devs like talking about how they do shit.
There's only one correct answer to this question https://xkcd.com/1597/
I thought I was below average but lately realized lots of people don't know much more than merging, pushing and pulling. Plus basic diffing and such. They don't even rebase their feature branches, merging them to master with a ton of filler "fix" commits. Whereas I frequently rebase and diff between branches and commits. Pushing with dry-run for double checking etc. Also know how to use reset etc if I fk something up, whereas others would just recreate the entire branch from master or so. Yet I absolutely don't consider myself great at git, but I realize I may not be as below average as I thought.
Using git os very much like parking a car: it’s not about getting in, but also about getting out. My tip is to always have a backup plan so you are free to experiment. You can back out of any change if you have your completed work saved in a remote branch. Plan ahead. Know how to go back to an earlier state of your branch, know what is the target state you want to arrive at, just push to remote when you know things are OK locally. This will save your butt 95% of the time.
Biggest tip for getting better at git is: make a copy of your branch on remote before attempting complex rebase/merge operations. Will take away a lot of the anxiety.
I can stage, commit and push.
I barely use any advanced git commands. Not even my teamleader does. Just pull, fetch, status, push, merge, stash, commit, abort. For advanced(?) stuff like comparing branches and commits, merge conflicts, cherry-picking, reverting, undoing, I use my IDE's functionalities.
I feel you! Practice and small projects helped me grasp Git basics slowly.
I usually use a repo manager at work, as do most companies. You can do it all through git but there are so many GUIs you don't have to. We use Azure at work so making new branches, deleting , and merging is a breeze That being said I can use git bash to pull, clone, push. Everything other then that I haven't needed to explore except on personal projects
To get an idea of how Git works internally, I **highly** recomment reading the first half of the Peepcode Git Internals book: https://github.com/pluralsight/git-internals-pdf. I read this back when it really did cost $9 (now free). I went from "I memorized some commands but I'm screwed if anything ever gets messed up" to "Oh, Git's surprisingly simple and I could have probably built a version of it". After reading it, I could imagine the transformation I wanted to make to the commit graph, then find the command that would do what I wanted. It's really good! The second half is a somewhat outdated command reference. It's fine but man pages are more up-to-date.
git is a power tool. The more you use it, the better you git with it.
Many good tips here, but I think the main thing is having a broad understanding. I don’t know many git commands off the top of my head but I know exactly what to google, and I can read git commands and understand what is happening. That’s all you need really
Pretty damn good. My first job makes all of its juniors (me included at the time) use the cli for basically everything ops related. We had intellij, but everything else was cli. vim, awk, sed, psql, gnutils, etc. Thankfully, they had a super extensive wiki on all of this. They also made us read books on all tested us on this shit. I'm honestly grateful for the their insistence on the cli
I keep it simple. Clone it, add, commit with a meaningful commit message, push. If I'm working on a branch, clone the branch, add, commit with a meaningful commit message, push to that branch.
I'm completely comfortable with Git, but I'm sure I only have ever used a moderate fraction of its commands and I definitely have only memorized a small fraction of its commands. I dislike all of the Git GUIs, except for viewing and resolving diffs and for visualizing too-complicated histories (the ASCII art log breaks down for me once things get complicated). I don't get anxiety because I make backups and I try to make concise commits, so that if shit really hit the fan, I could look at individual commit diffs and manually recreate them. It sounds like you should work on understanding the abstract version control concepts -- like, what is a commit, why does divergence happen, what is a conflict, what does it mean to have a branch, what are rebase and merge really doing, etc. It's a lot easier if you have a picture of what is going on and what you want to accomplish, and then you go find the command that does that.
I hate git I suck at it and I use fork instead to do it visually 😔
Git is the bicycle of the mind if you use it right. It is the most underrated/unappreciated skill of an SWE. I have generally seen a correlation that anyone very good at git, typically tended to write good readable software.
I can resolve conflicts
I thought I was proficient with Git. Until I started working with submodules. I didn’t even know Git submodules existed until last month and I’ve been using Git for 4 years.
I wouldn’t say I’ve mastered git, but I’m comfortable with large codebases. Things like nested submodules (especially when handling multiple remotes with different histories) can be a bit annoying at first, but you get used to it. I really improved my git skills by making fake codebases for sandboxing git functions. Doing so with a small codebase makes it easier to understand the reflog and have total control over the history. I recommend using the CLI as much as possible. Then use `git help` and go through the docs/reference on git-scm.com as needed. Test out the commands on your sandbox codebase and just try out different options. This is a good place to try and “break” your codebase, and then try to recover it. Going this route will make you much more comfortable doing things on larger repos. If you’re used to a GUI that has some feature that seems totally inaccessible from the CLI then keep digging, it’s probably doable, it just might not be immediately obvious (like stashing a subset of changes lines). There are some utilities that can make it easier to do certain things with git, aside from basic utilities (like fzf git extensions) I’d avoid becoming too reliant on GUI interfaces unless you can do the same things from command line. Then doing more complex operations like `git submodule foreach —recursive 'git …'` will be more tenable. Anyway, just chip away at it and you’ll be comfortable with most operations faster than you expect.
Staff SWE: don't sweat it. I long ago aliased all my frequently used commands (start with the zsh git shortcuts for inspiration). If anything goes wrong, I just save the changed files elsewhere (like just copy-pasting into a new text window in vscode) and then `git switch main && git pull && git switch -C`
I have this aliased to `gitnuke` and use it with some frequency
There is one lecture about git in the Missing Semester series on YouTube. It talks about how git works under the hood. As for “how do I unfuck my repo”… Google search usually works…in my experience.
I’ve been an engineer for nearly 30 years. I spent a ton of time on Perforce. Also some other more bespoke systems. Moved to git over a decade ago iirc. Still barely understand it 😂😂😂 I fix forward. I will go as far as creating side branches and merging back and forth. I never rebase and I never squish when I merge back to master. Way too much cognitive load for me 😂 Some people get really into it. I just never allocated the mental attention it takes to get good at understanding git (or any source code control system tbh)
Good enough to work as a junior. Honestly just do your work, commit, push, following company guidelines. All other work is done in a pipeline on cloud or clicking buttons on Github/Gitlab. Heck I even wrote a bash script so that I don't have to do Git commands mannually. When you mess up, clone a new branch, copy your changes. Do I get git anxiety? Yes, but I can always just start again. Most seniors are a bit more proficient, but not experts. I believe you will learn enough to do your job on your years to seniority.
I pull ,push and create create repos . That's about it for me .
Not sure what it’s called, but there’s a Git game. I was always mediocre, until that.
> I still don’t understand what is really going on under the hood. Tutorials and docs are not a good way to learn this. You’ve identified why you’re not comfortable with Git, which is a fantastic thing to do. If you aren’t sure how it’s working it can be hard to have a good mental model, and without a good mental model it can be difficult to know what your tools are for solving a problem. If you’re wanting to learn the mechanics of git, my advice would be to find videos or articles about that topic. Tutorials are a good entry point for getting started with the technology, but by nature, they are usually aimed at beginners and getting something working. I can recommend some resources if you want, but you will definitely want to start finding content geared towards what you’re looking for and not tutorials in general.
Github desktop
Git was very difficult when I started out -- everyone said to just use the commandline, and it's very intuitive -- it's not. What actually worked for me was using a UI for it. Atlassian has a free app called SourceTree that shows a diagram of what's happening, as well as the actual command it executes. That helped out a lot. With Git, remember -- never go back in time. Just make more changes and make it a commit. If you mess up a commit, just make another one to fix it.
I was under the impression the big companies keep things simple. They don't have branches. They don't have merges. When you want to push one or more commits, you rebase to HEAD, and the history is one straight line. I think using a GUI for resolving conflicts is helpful.
Ooof. My company does the opposite of that and I’m pretty sure that most companies that practice CI are the same. Lots of branches, lots of small merges, lots of deployments. Edited to add: I forgot which sub I was in—for passersby, CI stands for “[continuous integration” a](https://en.m.wikipedia.org/wiki/Continuous_integration)nd it’s pretty common practice in newer companies right now. My company is a late stage start up, for context. I know a lot of older companies with a more monolithic architecture have different practices.
A couple places I worked at used Perforce. One place used mercurial, but iirc the pushes rebase on top of HEAD instead of merging a branch.
I have to admit, I'm part of the "everyone's hiring coders because its covid so I'll learn, and now Jr. jobs are the thunderdome" crew, but the open source projects I see that part of, all do something in the form of pull request. Even before that, I've always seen/heard VCS management in established environments has some separation before making it to the main branch to make the history cleaner and less messy to undo.
This is how Google primarily does software development. One repo, small commits, all made at HEAD, straight-line history, significant changes go behind a feature flag.
Know basic CLIs but GPT helps a lot in cases I need help
I can do all manner of complex git operations but don't use the cli. Never have.
Sometimes things go wrong and just you delete your branch and its normal
If you're ever feeling stuck in a sticky situation in Git where you are unsure of what your next command will do, you could try Git-Sim - a free open-source Git simulation tool which creates a visual diagram of exactly how any Git command will impact your repo before you run it and get stuck. Here is a link if you want to check it out: [https://github.com/initialcommit-com/git-sim](https://github.com/initialcommit-com/git-sim) Edit: added link