How do I learn git?
I've done a few online tutorials and I know the commands like int/commit/push/pull and shit like that, but I still don't get what the fuck git is and how to use it.
I guess I'm looking for something that will spell out for me what git is and why I should want to git without just telling me to type commands for cryptic reasons.
>>53731350
Git is a version control system, which means that you can track changes to files, which is for the purpose of being able to go back to a working version when you break something.
It also provides a way in which to accept and make contributions with other people. Really any system could do this, but git (and other VCS) provides a standard way of doing it, so that you don't have to mess around with setting up an FTP server to get files or whatever else.
>>53731380
I don't get it.
Git keeps a local copy and a remote copy of your project. It can keep different copies of your project called branches. These are different versions of your project to work on, like development versions and release versions. Other people can also make copies of your project to work on called forks. Because git keeps track of changes, you can merge branches entirely or just specific changes. Git can also remember which commit made every line of your project, among many other things.
When you make changes that you want to add to a remote (the web version), it's called a commit. You can make commits locally and actually apply them (push them) to the remote later so that you can work offline. You can add files to a commit with git add.
Here's a cool example of the power of git-
I forked a project for work. I changed the title of the project in the README. Then, I added a script and a section about the script to the readme. I added my repository as a remote for the other project and then did "git cherry-pick" on the commit I made. The project title was not changed in the README, but the new section was added. The new section wasn't even at the end of the file, and my team-mate had also added lines. Git just knew where to put it.
~git gud
>>53731427
then kill yourself you retarded piece of shit
>>53731427
Imagine that you write some code, then you test it and you see that it works. Before you make any more changes, you'll want to make sure that the current version is saved. So, you can save the current version of the code in git by committing (with a message like "I added <some feature>").
You can continue to do this, so that if you ever make a mistake, you can go back to the version of the code that last worked. Git can essentially automate back-ups for you.
The other feature of Git comes when you can collaborate with other people. When everyone knows how to use the system, it's very simple for multiple people to work on the same piece of code. This is a lot easier than rolling your own solution.
Git has support for other features, too. You might want to "branch" in order to add a new feature to your code. This means that you can have two "trees" of code. One tree doesn't have the feature, and the other does. When you're finally happy implementing the feature, you can merge the two back together.
Think of Git like a clever system for backing stuff up and tracking when and why and who made changes to files.
A "commit" is a "version" of the file that you have updated. It comes with a message you can specify, so that you know what you did in that version of the file when you updated it. A commit stays on your computer until you "push" it to the server.
A "branch" is a separate development "timeline" that lets you implement new features across many commits while keeping the original (master) branch as it is.
With git, your team members can "clone" (get a copy of) your code and then commit and push their changes to the server.
Every commit in git is kept track of, so you know who's done what in the project. Everyone can see what commit was made when, so you know who to blame when something goes wrong.
Due to the fact that commits are made on your computer and then pushed, it means that you can do commits offline, then push when you're online.
Unlike many other VCS, you can use git on local filesystem. Here, test it yourselfmkdir test
cd test
git init .
echo abc > file.txt
git status
git add file.txt
echo 123 > file.txt
git status
git commit
>>53731350
Just read this mate:
https://git-scm.com/book/en/v2
The first two sub chapters spell everything out for you and will answer all the questions you have.
>>53731483
>I forked a project for work. I changed the title of the project in the README. Then, I added a script and a section about the script to the readme. I added my repository as a remote for the other project and then did "git cherry-pick" on the commit I made. The project title was not changed in the README, but the new section was added. The new section wasn't even at the end of the file, and my team-mate had also added lines. Git just knew where to put it.
I don't get it.
>>53731554
If everyone is merging to the same thing won't it end up breaking everything?
>>53731591
And if you don't get it afterwards, you might be retarded like what this guy >>53731508 said.
>>53731554
Thanks, that made sense.
(I'm not OP, though)
>>53731350
rtfm faggot. Literally a tutorial build right in.
man git 7 gittutorial
>>53731605
>If everyone is merging to the same thing won't it end up breaking everything?
Yes, this is why some projects have a system where everyone is tasked with a particular feature, or everyone has their own branch - which is then merged back into master when the feature is complete.
The merging process is manual, so you can see exactly what changes are being made before you actually write to the file.
Without branches, git would be really complicated to use because multiple people can of course work on the same file at once.
>>53731350
>>53731427
why do you want to learn git?
it's a version control system. the main use of these is allowing several people to work on a project at the same time. it provides lots of utility for branch administration and merging.
if you're working alone, none of this matters.
>>53731350
What did it for me was putting all my dotfiles on github and using it to sync my configs on all my work machines. It makes sense once you use it for a while.
>>53731427
>>53731648
To collaborate.
>>53731605
>If everyone is merging to the same thing won't it end up breaking everything?
that's why the version control exists. git tracks any and all changes to a project, and can restore it to any previous point at will.
if people merge their branches and shit breaks, you can just revert it to a previous point and then manually merge the branches in a way that doesn't fuck shit up.
>>53731605
>>53731648
Nope, git are useful even for single dev project.
Once in a while you might need to look back what you did in a previous change and git can show your code history.
Git is a source code management tool.
The best way to learn it is to have a project you are working on and then learn as you need it.
Then when you have the basics, expand on that.
I started using git before I even had code to work on.
I used it to make group work on latex less of a pain.
>>53731605
You can get conflicts if two people makes a change on the same file, in the same line at the same time.
This means you have to resolve it.
You will see a
>>>>>> HEAD
change a
======
change b
<<<<<< 123asfdjhsadh
And you can keep both or remove the one you don't think belongs.
It is a thing that remembers what you did. You can go back to an old thing that you did. Other people also have things that they did and you can put them together.
>>53731709
It's also worth mentioning that branches can be extremely useful even for single dev projects.
It's useful for separating in-development features in different branches and allows you to perform experiments or changes in a separate branch first where you can easily discard it without trouble, without it influencing your master branch, or "stable" version.
Git is a really handy tool to learn, but the only real way to learn is to actually use it for a project. At the moment you need something done with Git, you look up how it work and gain a better understanding of Git.
And trust me, Git is not difficult. I'm a complete and utter retard and I can comfortably use it and it's "advanced" features. If I can, anyone can.
you guys, i think the OP needs a proper tutorial. every retard coming in and giving a high level overview in their own words isn't helping him or anyone else.
>>53731795
>tutorial
In my eyes the only solid way of learning Git is to use it for a project (and therefore applying it in a real world situation instead of some tutorial). All you need for this is the Git docs https://git-scm.com/documentation , A search engine for when shit goes wrong, and a project to do.
>>53731795
OP has done tutorials. We've described the concepts involved and practical applications at a 4th grade level. He still doesn't git it.
OP here.
Just read http://tom.preston-werner.com/2009/05/19/the-git-parable.html and I think I'm actually starting to wrap my head around it. Gonna read
>>53731591
>>53731832
next. Thanks for all the help and mean insults.
>>53732115
Don't read more, get some actual experience with it instead. Set up a simple repo on github and do some small shitproject to test it.
Stop thinking you can learn everything by reading, actual experience is the best way of learning.
I work with a colleague that doesn't understand git after 3 years and I still have to tell him when to git pull, help him with
branching and reminding him of changing workbranch. All because he wont test it on his own and thinks reading more will help him.
Another approach is to use IDE with git plugins.
You won't learn git but atleast you'll familiar with git.
>>53731350
Use a GUI if you want like SourceTree. I'm not sure if it's available on linux yet
Heroku has Dropbox support
Just use that.
