Imagine you're playing with Lego, and you've made a thing. Let's say some cool looking monster.
You're looking at your Lego monster and you think "oh man, wouldn't it be ace if I added and extra eye over here?"
So you set about pulling out the bricks and adding in the eye and reassembling the monster. So, a lot of the monster is the same, but there are changes.
Now you look at your monster and you think "wouldn't it be great if it had an extra arm coming out of its back?"
So you set about pulling out the bricks and adding the arm and putting it back together.
And you keep making these small changes, but at some point you find you can't put the monster together because your change has made it impossible to build, and you can't remember how to put it back together in a way that works. Travesty! all that work! and you might have to start from scratch!
If only you could rewind time to the last point that your build worked.
When I write software, it is similar to putting Lego bricks together. When I make a change, it could be the wrong thing to do, so I need a way to get back to a place where the software used to work.
Git allows me to do this, because it will store a version of my code at a particular point in time, and then allow me to rewind time to that point. Because code is stored in a computer, that makes it very easy to make copies of it (unlike with Lego).
This gives me great flexibility, because it allows me to try out many ideas from a common starting point. I can throw away the ideas that don't work and keep the ones that do.
Creating a copy of the starting point to try and idea out from is called "branching". Keeping ideas and pulling them into the common starting point is called "merging".
Because branching is so easy, that means that you can give your code to other people, so that they can try out their ideas.
Merging is easy if the changes in each branch affect different parts of the code. Git can automatically merge the code together in that case. It gets more difficult when the changes affect the same parts of the code. If that happens then you end up with a "merge conflict". The conflicts can be fixed with tools, but it is good to keep changes a small as makes sense to, to make it easier to fix any conflicts.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Imagine you're playing with Lego, and you've made a thing. Let's say some cool looking monster.
You're looking at your Lego monster and you think "oh man, wouldn't it be ace if I added and extra eye over here?"
So you set about pulling out the bricks and adding in the eye and reassembling the monster. So, a lot of the monster is the same, but there are changes.
Now you look at your monster and you think "wouldn't it be great if it had an extra arm coming out of its back?"
So you set about pulling out the bricks and adding the arm and putting it back together.
And you keep making these small changes, but at some point you find you can't put the monster together because your change has made it impossible to build, and you can't remember how to put it back together in a way that works. Travesty! all that work! and you might have to start from scratch!
If only you could rewind time to the last point that your build worked.
When I write software, it is similar to putting Lego bricks together. When I make a change, it could be the wrong thing to do, so I need a way to get back to a place where the software used to work.
Git allows me to do this, because it will store a version of my code at a particular point in time, and then allow me to rewind time to that point. Because code is stored in a computer, that makes it very easy to make copies of it (unlike with Lego).
This gives me great flexibility, because it allows me to try out many ideas from a common starting point. I can throw away the ideas that don't work and keep the ones that do.
Creating a copy of the starting point to try and idea out from is called "branching". Keeping ideas and pulling them into the common starting point is called "merging".
Because branching is so easy, that means that you can give your code to other people, so that they can try out their ideas.
Merging is easy if the changes in each branch affect different parts of the code. Git can automatically merge the code together in that case. It gets more difficult when the changes affect the same parts of the code. If that happens then you end up with a "merge conflict". The conflicts can be fixed with tools, but it is good to keep changes a small as makes sense to, to make it easier to fix any conflicts.