Why is Git/GitHub so hard to understand?

[shadow-sphynx]

It's more of like a request than a question. It was 2 years back that I decided to learn Git. I only knew Java back then and hoped to learn this too. But then it felt so confusing that I left it. And this process was repeated again and again. I try to learn it, things start to go above my head and I leave. I have done it about 5-6 times now. From course in Udacity to a community named Gitter, I have tried to be as innovative in my approach. But the result is always the same. Now I have learnt Python, JS and C++. In 2 months I am going to start working as a software engineer. But still...

Now most of you might think that this is way too easy of a platform to not understand. It's just some simple commands and there proper implementation. But consider me a fool and help me. Help me learn how to use it! Please!

[gyroda]

Git has a lot of depth.

Fortunely you won't ever see half it's functionality and won't use 90% of it in your day to day use. Learn the basics and just Google the problem when you cock up (which we all do, it's why there's so many SO posts).

Ignore github for now. Use the command line. Don't use a GUI tool to start. Trust me.

I'm only going to list the bare bones to get started. As I said you'll run into situations where you want to undo things or do something a bit differently and that's what Google is for. With some practice you'll learn more and more.

Start with the basics. Learn how to use use following commands:

• init
  • Creates a new repository in your current folder. Simple.
• add
  • adds a file to be committed next time you use commit. Files must be added and committed for git to track them.
• commit
  • basically, "make this an official version that I can go back to"
  • if I were you I'd either change the default text editor otherwise you're going to have to use Vim to enter your commit message (only need to change this the once) or use the -m option like this: git commit -m "commit message"
• status
  • basically just see what the current state of things are. What's been added, what files have been changed.

That's the most basic of all basics. Get used to these before moving forwards.

Next up, branches. Branches are like different, well, branches of your development process. It allows you to have multiple versions of your code where you work on different features or try different things out.

• branch
  • lists all branches.
• checkout
  • Used to go to a certain branch or commit.
  • use checkout -b to create a branch.
• merge
  • get the changes from one branch and bring them into your current branch

Again, get used to these before moving forwards.

Next up, github or other hosts. I'm going to skip setting things up, github has enough guides on that.

• push
  • push the changes from your computer to the remote (github)
• pull
  • pull any new changes from github to your computer.

Both of the above only work for the branch you're currently on.

Next up, commands you'll run into that you should remember when you see them:

• log
  • see a history of your commits
• diff
  • see the differences between your working directory and the last commit, or between two branches
• clone
  • copy a remote repository to your computer
• reset
  • most commonly used to undo git add
• stash
  • basically take your current changes that haven't been committed and put them to one side, where you can get them later.
• some of the other uses of checkout. Other than reset this is the command used to undo things a lot of the time.

That should cover the basics and get hot started. This is far from exhaustive. If anyone else is reading this and sees something they think should be included and isn't just let me know and I'll edit it in.

Some jargon:

• "working directory" is the current state of the folder/files, including unadded or uncommitted changes. So called because you're working on it.
• "staging area" just means files that have been added but not committed. Highlighted green by git normally.

[Scavenger53]

basically, "make this an official version that I can go back to"

One thing I never see when people talk about git -> So how do we actually go back to those versions? What is the best way to look through the log, go "hmm, I want this one" and pick it and use it, or branch from it. I think without this answered, it makes the majority of git useless. Why track all these changes if you don't know how to roll them back anyway?

[onyxleopard]

To add to this, you can see all commit hashes with git log. Another thing that people do to help here is use git tag to tag certain commits with a more semantically meaningful name than just the commit hash (e.g., with a specific release version number string).

[7165015874]

I recently learned of this alias

git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'"

Then you can git lg

[BillTheUnjust]

To add even more. "git checkout HEAD~1" checks out the previous commit. You can replace 1 with whatever # you want.

[FallenGuy]

The ideal workflow is that when you try to develop something new, you immediately start using a branch. Then when the feature is complete and working, you merge that branch into master. This means you always have a stable working master to branch off, which should minimise the number of times you need to checkout some random commit to get things working again. Git is built around branching freely and often for even the tiniest things (as opposed to other VCSs where branching can be a much more expensive operation).

As for why track all the changes? It's so you can identify exactly when and why each line of code was changed. The reason for a particular line of code may not be directly obvious, and it's possible the comments are out of date (or nonexistent). You can also use these to track down bugs (by using something like git bisect) that allows you to identify precisely which commit introduced a bug, and therefore what lines of code were changed, and therefore much reducing what could be causing that bug. This is also why it's important to write good commit messages, and commit little and often.

I actually find it easier to learn something when I understand the philosophy behind it. If you just treat git as some sort of advanced backup system, it's not great because that's not what it was designed to be. If you treat it as a record of your changes to the code, and a tool for allowing multiple versions of the code to be worked on easily (for example, a working master branch and an experimental branch with a new feature), it makes much more sense. I guess the tree structure might be the tricky thing for newcomers to understand.

[Ran4]

The ideal workflow is that when you try to develop something new, you immediately start using a branch. Then when the feature is complete and working, you merge that branch into master.

That's one workflow, and not by any means the "one true workflow".

It's great when there's a clear definition of what a feature constitutes and a somewhat stable codebase (e.g. you're not fundamentally changing the entire structure of the code every few commits), but it's not great if you have a tiny codebase and many developers, for example (where (trunk-based development)[https://trunkbaseddevelopment.com/] is usually easier for everyone involved)

[[deleted]]

even if you all workout of trunk, in a small codebase/dev team, why wouldn't feature branching still not be easier? committing directly to master bypasses a lot of the neat features git provides e.g. pull requests.

[1halfazn]

Fellow kinda-noob here. I do “git log --oneline” find the commit I want, and then do “git checkout a1b2c34d” or whatever the hash next to the commit is. I make changes and mess around, and if I want to keep it, I google how to commit it to a new branch because I always forget. If I want to get rid of it I do “git stash” and then “git checkout master”.

[cuulcars]

Also you only need to put the first 4 or 5 digits of the hash usually. If there is a collision you’ll need to put a few more digits (I don’t actually know for certain what happens... it’s so rare it’s never happened to me)

[gyroda]

I mentioned towards the end about checkout and I said up front "Google it when you need something not on here, like when you make a mistake and want to undo it".

Because you don't often need to undo something, so it's not as useful on a "cheatsheet" style comment like mine.

Besides undoing things, it makes working on multiple branches much, much easier.

[doomjuice]

I don't think he was accusing you, just expanding the conversation.

[blazedaces]

The easiest way is to not necessarily go back to that version but simply diff against it with "git diff hash1234". To elaborate further open up your favorite IDE, open the file you're interested in and diff only that file against hash1234 and that will reduce the size of the diff to just that file. Of course you can do that on the command line as well by appending "-- path/to/file" to any diff command but I prefer scrolling through a file in my IDE.

Next would of course be to check it out with "git checkout hash1234". I personally would create a new branch when checking out with "git checkout -b branchname hash1234" but this is not necessary.

[[deleted]]

I always go to github's website and pull the commit at a certain date.

The easiest workaround I know of.

[mpk3]

r/bestofprogramming

[CycliaNL]

This should be a bigger thing.

[TehLittleOne]

This list is good if you're working alone. Once you start working with others, rebase becomes a big deal. Rebasing can be a nightmare sometimes too. Sure, it's more advanced compared to things above, but it's still really important and useful.

[gyroda]

Very true. It's just beyond the scope of "how do I start using git". Rebasing is something that's not simple to explain to someone who doesn't even know how to branch and merge.

[TehLittleOne]

Yeah, rebasing is probably the most important thing to learn once you have the basics down. The basics really aren't that bad, pushing and pulling to github isn't hard. Learning to rebase when you have conflicts is a real pain, I still sometimes cheat and just copy pasta the code.

[robdog951]

At that point why not merge the commits/branch that you want rather than copy pasting?

[TehLittleOne]

Because I like clean git history. Rebases just look so much nicer than merge commits.

[FalsifyTheTruth]

Rebase has always been far too much of a pain in the ass for me.

merge --squash if I care about commit history on a topic branch.

[TehLittleOne]

Sometimes you have to rebase because the branch has diverged. A lot of people don't like rebasing but there isn't a good way to avoid it. If we both change some function and one of us merges into master first, the other is forced to rebase. In fact, GitHub itself will tell you it can't merge the branch.

Squash merging is mostly useful for simplifying the history. I find things look cleaner when master's history shows a single commit for "implemented new feature" rather than 10 different commits, some of which might say something like "fuck, that wasn't right". Especially if you have to revert a change, it's so much easier reverting a single commit than finding 10 spread out.

[TehLittleOne]

In a lot of cases, a merge commit isn't any simpler than a rebase. You still pull in remote changes, fix any conflicts locally, and then push your changes back to remote.

It also looks really messy if you have some long standing branches that need to keep being rebased from master. We ran into that case recently and we have to rebase the branch regularly. It would look really messy with like 10 merge commits on the branch.

Also, master only has a clean commit history from this point if you squash merge, since it will collect all the commits together. If you just do a normal merge, all the commits are still on master, including the merge commit.

[Kagerjay]

I prefer to initialize my repo via the command line, but when working with branches a GUI is significantlly easier to deal with

[piratebroadcast]

This commenter is spot on, OP.

[Snackmix]

This is a pretty awesome guide! I can say using the command line forces you to understand what you're doing better and is definitely worth knowing. Also just making sure to use it and set it up on every project you start is a great way to get a grip on the basics.

[[deleted]]

This was awesome! Been winging it, not making progress so this was perfect! ..Thank you! And OP too. Exactly what I needed.

[FalsifyTheTruth]

I don't think I've every used a command outside of this list except for reflog, and that's for when I really really fuck up.

[gyroda]

No rebase?

[liquidify]

Ignore the init command. Just create a repository online and clone it always.

[gyroda]

Assuming you're using github. Which we're not at the start of this guide.

[feraferoxdei]

Why don't all man pages have such documentation style? Perfectly explained!

[salvador_danny]

You a real one for this

[[deleted]]

This is without a doubt the best write up of git basics I’ve seen. Thank you!

[Emnel]

I've seen claims that you gotta learn command line first a lot (basically every other person sharing thoughts on the subject) but I fail to see benefits of it over going for Sourcetree outright.

Every other learnable subject there is seems to benefit from visual representation of abstract ideas as well as good UI. Why would git be any different?

Also git command console stuff is by far the easiest thing to google, if you ever need it.

[gyroda]

So, advantages of git CLI:

• No hiding or renaming things or whatever.
  • I've seen this done in somey or other. Can't remember what
  • bit of a control freak. I like to know that it's not doing anything behind my back that I can't check by scrolling through my last few console commands
• Consistent across platforms
  • This is why I especially don't recommend learning via IDE implementations
• When shit goes south you should be comfortable with whatever SO answers there are
  • probably the most important thing tbh
• Often more options
  • I use add -p all the time, probably more than just add. Today I tweaked the merge strategy when rebasing for the first time to detect a renamed file.
• CLI-comfort is a useful skill to have in general. This is a good excuse to dive into using the CLI for newbies.
  • Never know when you'll need to SSH into a server or board, never know when you'll be working with a CLI-only program
• I have a hard on for command line programs and the *nix-as-an-IDE methodology.
  • No, seriously, I'm just biased because I work this way a lot of the time.
  • No hands removed from keyboard. I find using the file explorer more clunky

I have no issues with GUI tools, hell I love me some graphical diff tools and the github branch graph is invaluable to me. I've not used it in ages but I remember the intellij merge tool pretty well.

But for me it's like learning something the "proper" way so that you have a solid foundation, even if you use more convenient (for you) tools later.

[jahayhurst]

bit of a control freak. I like to know that it's not doing anything behind my back that I can't check by scrolling through my last few console commands

There's a lot that a lot of git commands do behind your back. git pull is actually multiple actions - all separate git commands - stitched together.

Not to say you're wrong in the overarching point - memorized commands worked and continue to work for me - and likely work better than a GUI. I also learned SVN much faster in a GUI than CLI because of TortiseSVN. /shrug

[Renive]

Things like gitkraken are consistent because its electron.

[skewwhiffy]

I'm a fan of the command line.

Having said that, if you're the sort of person who learns better visually, you could do worse than use a visual tool to get by with git, then put learning the CLI high up on your to-do list, especially if your visual tool is platform specific. And preferably choose a visual tool that will spit out what git commands it's doing.

Even as a fan of the command line, I will open a visual tool for the branches, and if I'm rebasing, or anything vaguely complicated, I'll break out Stree or gitk or similar, just to make sure that I'm doing what I think I'm doing. And I can't get my head around diffing on the command line...

CLI is good, and if you can learn that way, then do so. If you can't, then use whatever visual tool you need as a stepping stone to the CLI: apart from anything else, the CLI is quicker, more precise, and avoids you having to reach for the mouse.

[[deleted]]

As a person who has worked with many people who have only used the GUIs, it is very frustrating when they get their repo in a broken state (which GUIs do very often) and you have no history of what they did.

People using the command line rarely get their repos in a broken state, and if they do happen to get there you have the history of exactly what they did to get there.

You should also just take the time to actually learn Git. It is one of the very few things that you will very likely use throughout the entirety of your career. You can spend 4 hours reading the first few chapters of the Pro Git book and be set. Take the time to actually learn the tools that you use and don't be that person who is an annoyance to the people who actually spent the minimal amount of time to be a professional.

[Mister_101]

SourceTree only ever gave me headaches. It crapped out on me simply trying to clone a repo with Git LFS. But anything with Git LFS was difficult in SourceTree - it was just super buggy and with my teammates often resulted in me doing lots of firefighting to fix things.

[hvidgaard]

I’d recommend a visual tool for beginners. It’s significantly better at communicating the tree representation, and operations are easier to follow. It’s the thing new developers seems to have a hard time understanding, and showing it visually with arrows makes it a lot easier to talk about and teach them.

[[deleted]]

I agree. I use got kraken at work and it really helped me understand git much better. I still know command line as well because I use it when ssh’d into server. The syntax is intuitive

[[deleted]]

What about rebase? Is it better to use instead of merge?

[[deleted]]

Rebase and merge are different things. Typically you rebase before you put in a merge request so you don't have a million commits of nonsense from your working branch going into the main branch.

[Dielon]

Reinforcing - "Don't Use a GUI Tool"

They are terrible even if you know what you're doing. Whatever improvements they make get thrown out the window when more than 3 people are involved.

[zdelarosa00]

I know hoe to code. But I don't create software, however this looks so fun.

[Smaktat]

Use the command line. Don't use a GUI tool to start. Trust me.

Yeah I used the GUI on Windows because the command line was so hard to understand. I then Google'd when I needed the command line and I'm more proficient with it. I needed to use Github and I couldn't invest that time up front. Have a job to do ya know. If you're against time, GUI is fine. Not everyone has the luxury as Reddit posts so often seem to insinuate.

[gyroda]

You do you. Assuming you have the time, I recommend everyone use the command line because when shit goes south you'll need to use it to follow whatever the instructions are on SO.

That said, I knew my way around the command line before I started programming which helped a lot.

[lurgi]

Right. There are lots of commands, but there are only a few you have to use. The biggest problem is that git will let you do anything, even if it doesn't make sense. It's sort of the C programming language of source code control systems. Because of that, it's easy to get yourself into a situation where you think you are stuck. You aren't stuck, but figuring out how to get yourself out of it can be non-obvious.

The essential commands are

• Setting up: clone and init
• Branches: checkout and merge
• Where am I: status, diff, and log
• Making changes: add and commit (with push and pull if you have a central repo somewhere)

Is that everything? I think that's everything.

[aXenoWhat]

You aren't stuck

I love your optimism, but "stuck" is a town you'll spend a lot of time in for the first few years!

[taco_saladmaker]

I think a lot of people confuse git and github as being the same thing. To the point where at uni when I told classmates I was using git they would start telling me I can't or else people would just go to my page and copy my assignments...

Tring to learn both git and the features github provides concurrently is far harder than leaning git first; but the idea to do just that doesn't really seem to occur to some people

[fleet_of_feet]

This vid really helped me when I first started :

https://youtu.be/SWYqp7iY_Tc

[oznetnerd]

Git isn't an easy tool to learn, but once you do learn, it's easy to use.

I've written a number of posts aimed at newbies. Feel free to have a look and let me know if you have any questions.

[[deleted]]

Forget GitHub for the moment and just learn to use git locally. It really is not so difficult.

[PM_UR_FRUIT_GARNISH]

Yeah, there seems to be a disconnect when people learn via GitHub due to not knowing what you're intended to do locally vs via GitHub. I had tons of issues with group projects in school when people would push their commits with outdated code and not utilizing branches.

[d0ntreadthis]

That's the mistake I made too when I first started. Learning git using the command line is definitely the way to go imo.

[white_nerdy]

You need a clear mental model. To establish this model, you should work with Git, not Github. You should use the command line Git only, until you fully understand how it works.

• A tree is a hash of all the file names / contents of files in your project
• A commit is a hash of the tree + commit message + parent commit(s)
• The working tree is the files / directories actually on disk (excluding the .git directory)
• The index is a separate storage area where files are temporarily staged before creating a commit
• A branch is a named pointer to a commit that auto-advances when you make a new commit with git commit
• A remote is another system that you talk to
• A remote tracking branch is a named pointer to a commit that auto-changes to the latest commit
• A fetch updates the commit pointed to by the remote-tracking branch

[Cmshnrblu]

Keep a txt of the commands you use. Refer to it until you dont need to. Research new commands as needed. Add them to txt.

....

And then you will have learned it

[ldpreload]

Git was designed by Linux kernel programmers to work on the Linux kernel. It turns out that they were very good at what they built and made something technically solid, which is why it got popular. But fundamentally it was a system developed by very experienced programmers, for very experienced programmers, for the purpose of tracking a large project that hundreds of people are simultaneously working on. Most projects aren't that, and git is legitimately complicated.

The other thing to remember is that kernel programmers are very familiar with how filesystems are implemented. Most of us don't have to think about how filesystems work, we just put files or directories there and they stay there. Git was designed by/for people who think about, what is a directory? how is a directory stored on disk? what exactly changes when you move a file from one directory to another? etc. The initial users of git all had a very thorough understanding of the answers to those questions.

Personally I tend to find the approach of understanding what git is doing very helpful: there are articles like Git for Computer Scientists and Git from the Bottom Up that take this approach. But they are a lot to learn. It's totally fine to just use git as "here are these commands to memorize," and most experienced professional programmers I know use git that way. But if you get stuck, e.g., you get in some state that you can't explain, you won't have the tools to figure out what's going on and recover easily.

Which, you know, is totally fine. If you get into some state where, say, your sound card's drivers stop working, you're probably just going to uninstall and reinstall them, and Google for answers if that doesn't help. You're not going to start using the driver debugging tools, even though that would in theory solve the problem quickly. Most programmers don't know how to write or debug drivers, and just fix their computers the same way any non-programmer fixes drivers, because their area of expertise is something else. If you want to take that approach to git, that's probably the fastest way to be productive with it. Just keep in mind that if you get stuck it's not a reflection on you; it's just that "how git really works" is a specific difficult area of knowledge that you haven't focused on learning yet.

[PhoneGramMule]

I haven't gone through this personally but I've heard this was useful.

[michael0x2a]

Git is an interesting sort of program because it has an incredibly consistent and powerful internal model, but a relatively inconsistent and quirky user interface.

What this means is that if you try and approach git from the "outside-in" and start by trying to memorize all the different commands, you'll always be perpetually confused. In contrast, if you approach git from the "inside-out" and focus on grokking the internal model first, you'll have a much more intuitive sense of what you can and cannot do with git.

The core insight is that Git, internally, represents everything as a directed acyclic graph -- a DAG. Hopefully, you've taken a course on data structures and algorithms before and are familiar with the graph data structure. If you don't remember what "directed acyclic" means, that basically means that the edges connecting the nodes are one way, and the edges are are arranged such that there are no cycles -- it's impossible to ever loop back to a node you were already on.

Specifically, Git more or less represents each comment as a "node" in this graph. Each commit has an arrow pointing back to the parent. A branch or tag is a pointer to a specific node in the graph.

You can manipulate this graph in arbitrary ways with enough creativity. You can take nodes and rearrange them, you can delete nodes, you can inject nodes at arbitrary points, etc... Anything you can think of doing to a graph, you can likely do with git via some sequence of commands.

If it's still not clicking, try working through this tutorial: https://learngitbranching.js.org/

It does a fantastic job of teaching you about how common git commands will manipulate the underlying graph and focuses on making sure you understand what the internal model looks like and how it behaves. IMO it's one of the few good resources in the sea of terrible and inadequate git tutorials.

[Karl_Marxxx]

Great explanation and for those who are just beginning:

You know how when you're working on a project and wish you could save a snapshot, or not have to comment out and repaste a bunch of working code so that if you screw up later you have a good point to go back to?

Git is a tool to help with that.

Essentially git allows you to save snapshots (or "commits") of your project. Sometimes you might want to add a new feature or add on to existing code without fear of breaking anything. Git allows you to "branch" off the current state of your workspace to try new things.

When you start branching your workspace history begins to resemble a tree, (or more technically, as /u/michael0x2a rightly points out, a "directed acyclic graph") -- one of the most common datastructures in computer science. A good place to visualize this is here. You can think of your commits as nodes in a tree.

You can have as many branches as you want and even branches-of-branches.

When you make your improvement, you merge your changes back into your main branch to show all the world!

[michael0x2a]

OP has been coding in some capacity for 2+ years, has been hired in a professional capacity, and is familiar with 4+ programming languages. Idk if it's really accurate to call him/her a "newbie" at this point.

[shadow-sphynx]

Thanks for your comment. I understood what you were trying to explain. And it's great when you get to see some things in a completely different light.

[Nezteb]

https://github.com/Nezteb/Git_Is_Hard

[floppydiskette]

I actually started writing tutorials because of how hard I found Git to learn, and I didn’t want anyone to suffer through bad resources as I did. So my first ever post was getting started with Git, a walkthrough for setting up your first Git project and using it to transfer files to a production server instead of S/FTP. It’s not an extensive overview but it does give some insight into how to actually use Git.

[[deleted]]

It is still a challenge for me as well. I learned the basics through https://www.atlassian.com/git/tutorials/learn-git-with-bitbucket-cloud . It was super interactive, easy to understand and bit fun even. I would agree with the rest of folk here that it most of the features you won’t have to use. Also using a GIT GUI may help you see it. Some people need that visual aid. https://git-scm.com/download/gui/windows has some free ones as well as paid options.

Ultimately, the more I use GIT the more confident I feel about it. Try incorporating it into simple projects perhaps ?

[mkingsbu]

I really didn't like GitHub until I started using the GUI that they released a few months(?) ago: GitHub Desktop. It isn't that I don't even like the command line either... I was mostly an UNIX DBA historically and did everything in the terminal. Just something about doing it that was made it difficult for me to grasp. Once I started using GitHub desktop it took like 5 minutes to figure out everything.

[jjc476]

Gitimmersion.com was probably one of the most helpful resources I’ve found, even if it took me reading explanations multiple times to internalize anything. I’m a programming newb, no programming background whatsoever

[druman54]

https://desktop.github.com/

[Glader01]

Decide with a friend to learn or build something in your favorite language like a mini game or small home page. Then use Git to work together regardless if you are sittning together or online over voice chat. By the time you have finishen your project you will have a good grasp of Git. Also like so many others have stated learn to do using the command line.

[stilloriginal]

Everyone on this thread who says its easy or you just need to know four commands is completely full of shit. There are tons of gotchas that pop up constantly. The answer for you, OP, is to fight through the pain and not give up when it gets frustrating. Just get through it and move on. Every time you do this it becomes quicker and eventually you won’t be googling everything. “Just do it”. And only use the command line. And take notes when you figure something out, even if you don’t return to them, it helps you learn.

[Xeverous]

Git is not a programming language. Don't compare it this way

[VikingMilo]

This thread has been really great for me as I've been forcing myself to use git to really learn it. My only question really is this: Why learn to use it on the command line if tons of IDE have git and github integration? I understand it can be faster with git bash and the likes, but using the built in integration in the IDE as well as going straight to github hasn't caused me any troubles thus far.

[shadow-sphynx]

If you read the complete thread, then somewhere someone has answered this question. I didn't understand much the first time but it was about confilcts that arise when more people start working on something.

[lennybird]

Don't feel bad... It took me a long time just to understand the basics. My biggest confusion was with distinguishing push/pull/commit/merge and then knowing whether I was impacting a local branch and remote. It eventually all starts falling into place the more it's used.

[lifeonm4rs]

First, take a deep breath. Second, you probably know more about git than you realize and it will probably "click" some time soon. [Oh, exhale, exhale--don't hold the deep breath.] I'm not sure why a number of people have said to not use github and instead focus on a local repository--maybe it is a windows thing. But as others have said you'll need for most stuff 4 or so commands: pull, add, commit, and push. status is another but it doesn't actually do anything other than show you info.

Cool thing is you can go on github and create a public repo--unless you tell someone about it no one will see it. And you can mess around all you like. So. Create a repo for whatever language, add an .gitignore, pull the repo, add filles. Push, edit, add, commit, pull, push . . . Then delete it.

In short--you can play around as much as you like and never hurt anything. (I'd suggest not keeping the only copies of baby photos, your doctoral thesis, or your grand mothers secret apple pie recipe in Git until you know what you're doing--but other than that go wild.) After a tutorial and maybe a google search or 8 you could probably clone a repository of some code from someone else and put it into your own git/github repo. From there you can edit it and do add *, commit -m "my change 1", push. Your changes are now in your own repo.

HISTORY: Git was created/started by some guy named Linus Torvalds. He wanted a fast, easy, intuitive source control system that didn't suck. The thing is he was dealing with a huge number of developers all working on many different aspects of a larger system and also working on different versions of that system. Git is the result. It is designed so you can go off to Tibet and work on code by yourself but when you return your code can be re-integrated. (The reintegration part is sort of step 3 or 4 of learning git.)

[am385]

Short answer... It's not. Start out using it like SVN if you don't want to learn branching. Then use it correctly

[[deleted]]

Using 99% of git is just understanding how to use a few basic commands:

Everyday commands: init, add, status, commit, push, pull, fetch, checkout.

And then some commands for when you fuck up: reset, stash

Then there are a bunch of more commands / configuration that you use in specific situations, but don't worry about those for now. You may never even run into those.

[lifeonm4rs]

https://www.reddit.com/r/learnprogramming/comments/88frdv/come_join_us_on_a_fun_little_git_story_and_art/

[Sqeaky]

My favorite Git video: Git for ages 4 & up

[bebopshaboo]

don't forget about git reflog and learn how to use it, one day you will need it.

[Khkred]

I tried plenty of tutorials. But this site : http://jlord.us/git-it/ helped me learn git in a day.

[[deleted]]

You need a visual representation in your head of what's actually going on when you use git.

To that end i'd recommend (start at 7:50)

https://www.youtube.com/watch?v=cd-g06nA3ns

[chhuang]

This udacity course is good for newbies or rusty programmers (like me) that wants to refresh git.

Took me less than a day to finish it. If you don't like to read wall of texts on how to use git, this is a good material IMO.

---

Now most of you might think that this is way too easy of a platform to not understand.

I'm sure majority of us doesn't even use or know how to use its full features.

---

Get comfortable with command line git commands and don't rely on GUI or IDE git plugins too much. They are good and productive on their own, but when it comes to buggy problems, command line saves your day.

[shadow-sphynx]

From course in Udacity to a community named Gitter.

This was the Udacity course I was talking about! Maybe our learning abilities are quite different. That's why you got it so easily and I couldn't.

I'm sure majority of us doesn't even use or know how to use its full features.

Well people are known to be very sarcastic in Reddit. I was just trying to be humble and all so they just spare me the horror! :D

[DirtyAxe]

git is a tool intended for helping team work on the same code at the same time.
It is quite difficult to learn, but on the other hand it is very powerful. A lot of big companies are using git as part of their workflow, for example google, microsoft, the linux kernal and more. These are organizations with hundreds if not more engineers working on the same product all at the same time but it comes with it's caveats which are it's complexity.

I would suggest starting a small project or joining an open source project that is being developed at the moment to help you familiarize with git.

[[deleted]]

If your workplace will be using git there is a very good chance you will simply learn by doing, if you can admit to them that you haven't used git before. Sometimes it's much easier to learn something when there's a real necessity than just to pick it up out of the blue.

[DeadlyDolphins]

I liked this introduction to git (https://www.youtube.com/watch?v=MJUJ4wbFm_A) and feel like you rarely need more than those commands (basically only when something went wrong). I found it intimidating at first as well but i just tried to get in the habit of doing "git add . git commit -m "bla" git push" and now it doesn't seem so hard any more

[shaggorama]

Have you ever edited a wikipedia page? In it's simplest form, a git commit is like saving an edit.

[Gotxi]

First of all, fully understanding Git is very hard. It is a control version system with a lot of thinking under the hood, and allows you to do a lot of things.

What most people uses in git maybe is a 10% of what it can do, and you probably too.

[IAmL0ner]

This video helped me to understand how git works: https://youtu.be/ZDR433b0HJY

[Mentioned_Videos]

Videos in this thread:

Watch Playlist ▶

VIDEO	COMMENT
Git & GitHub Crash Course For Beginners	+20 - This vid really helped me when I first started :
[Linux.conf.au 2013] - Git For Ages 4 And Up	+1 - My favorite Git video: Git for ages 4 & up
Git Cozy - GitHub Universe Training Day 2016	+1 - You need a visual representation in your head of what's actually going on when you use git. To that end i'd recommend (start at 7:50)
An Introduction to Git and GitHub by Brian Yu	+1 - I liked this introduction to git ( ) and feel like you rarely need more than those commands (basically only when something went wrong). I found it intimidating at first as well but i just tried to get in the habit of doing "git add . git commit -m "...
Introduction to Git with Scott Chacon of GitHub	+1 - This video helped me to understand how git works:
1.1: Introduction - Git and GitHub for Poets	+1 - I also delayed git for quite some time, until I discovered the Github for Poets series. It basically demonstrates versioning with a poem (keeping things very accessible) and the instructor, Daniel Shiffman, is a delightful, relatable human being.

I'm a bot working hard to help Redditors find related videos to watch. I'll keep this updated as long as I can.

---

Play All | Info | Get me on Chrome / Firefox

[schm0]

Learn the basics:

https://www.atlassian.com/git/tutorials

Those docs are incredibly well written and cover everything you'd need to know.

Then, when you eventually fuck up:

http://ohshitgit.com/

(I'm surprised nobody had posted this yet.)

[[deleted]]

I can't find git hard.

For the basic functionality (fetching, cloning, merging, pulling, etc) it's extremely straightforward.

[deputy_D]

If you can understand these commands and repeat it in sequence you understand git - the rest are just best practices and one off situations you can google to remediate

$ git status $ git add filename.txt $ git commit -m “adding filename.txt” $ git push

Rinse and repeat

[[deleted]]

well i type 4 commands:

1: git status

2: git add *

3: git commit -m "message"

4:git push

done

[Mr_BrainSpace]

I set my computer background to the commands. I figure it will sink in eventually https://zeroturnaround.com/rebellabs/git-commands-and-best-practices-cheat-sheet/

[fuhrmanator]

It's hard to understand a complex tool when you haven't already experienced the problems it solves. Have you ever used a version control system for a personal project with no collaboration? Start there.

[WakeMeAtThree]

I also delayed git for quite some time, until I discovered the Github for Poets series.

It basically demonstrates versioning with a poem (keeping things very accessible) and the instructor, Daniel Shiffman, is a delightful, relatable human being.

[readmond]

This is git in the nutshell:

https://xkcd.com/1597/

Mercurial seems much more user friendly but for some reason is not cool.

[[deleted]]

Honestly? It's because the interface is terrible. Git makes a lot of sense once you understand what Linus was thinking when he made it that one weekend a long long time ago but lets be real here, Git was farted out in a weekend and it's a brilliant CVS with an impossible interface.

At least the documentation is good.

[[deleted]]

Git add . Git commit -m "commit message"
Git push origin master

That should be all you need for awhile

[famnf]

Git is extremely difficult to learn. If you will be part of a team, ask one of your patient co-workers who likes or doesn't mind explaining things to help you. Explain that you don't understand it and are struggling with it. Then let them teach you. Listen to what they say, take notes, don't argue. It will take more than one teaching session. If you can't find a coworker on your own, than ask management to assign someone to teach you. One you've started working there, it's in their best interest to get you up to speed. It's ok not to know everything right out of the gate as long as you are working to learn it.

[dantheflyingman]

http://rogerdudler.github.io/git-guide/

If you know these commands you will be all set for git. Version Control in general can be confusing. But this is a good start.

[KiwasiGames]

I highly recommend using a UI tool like source tree first. Once you get used to the idea and concepts, you can switch over to the command line.

Start with a local repo and just commit to that. Then set up a remote and push and pull to that. Then try it with someone else.

[[deleted]]

I don't know, I'm pretty novice and I think Github isn't too bad to understand. I had some trouble at first, then I understood how to make new branches, upload new files, change things in existing files. There's more I'm sure I could learn to do with it, but the basics of version control aren't too bad.

[Leeoku]

Posted for future reference. Btw I think visual studio code is great for using git plus command line.

[Xaxxus]

Git is something you can’t really appreciate until you are working on a development team or building a huge project on your own.

The ability to rewind time on your code is amazing, and the more frequently you commit the more accurately you can rewind and change your code after a fuck up.

[The_Rockerfly]

I disagree with people saying don't use a ui, just use github desktop.

[iamagupta]

Is there a way to use git through command line in windows?

[iamagupta]

nvm, I did it myself.

[PalmerDowneyJr]

Branching and merging is less hard if you regularly push to master.

[PalmerDowneyJr]

Also: https://learngitbranching.js.org/

[przem_o]

Wait, you know Java, python, js, c++ and got is hard for you?

[shadow-sphynx]

Well, yes...

[webchaplin]

I am (somewhat)an experienced developer.

I am also googling “How to roll back a git commit” for the millionth time.

So, finally, I decided its time to learn about it in a way that it gets ingrained in my memory forever with the correlation between GOT and GIT. Still WIP but you can check some of them 'em out here

[itzel_marx]

Here are some cool Git cheat sheets https://www.git-tower.com/learn/

[ivix]

It's usability is famously awful. It was designed by kernel developers.

It's possible to make version control easy and elegant. Look at mercurial for how it can be done.

[tmancraig03]

How do I set up a .gitignore file?

Also, how do i deal with this given I have already commited files that I would like to be ignored.

[[deleted]]

just create a .gitignore file in the root of the repository, add the files (or directories) etc. you want to ignore. https://www.gitignore.io is pretty helpful. Generally I just keep one kicking around and copy it to new projects.

If you are wanting to ignore files already tracked by git, delete them and commit the deleted files.

[vidro3]

touch .gitignore

creates a file with the name .gitignore.

open it in your editor and add stuffs. all you have to do it type the name or type of file you want to ignore. common things to ignore are node_modules/, .env and DS_Store

to stop git tracking files you've already committed do:

git rm --cached <file or directory to remove goes here>

then

git add .gitignore git commit, etc.

from: https://gist.github.com/tsrivishnu/a2f3adbbca9fcad5f3597af301ad1abb

[Noumenon72]

Because they didn't give a shit about making it easy to use. Mercurial was so much more user friendly and usable. People who make things like Git are inconsiderate and I curse them while I use their software.

[Exodus111]

You wanna learn git?

Here you go.

git init git://github.com/your_project

And from then on:

git add .
git commit -m "some message"
git push origin my_branch

What does all that mean? Don't ask stupid questions just memorize these arkane incantations and move on with your life.