You can Git there too :)
The ways that I work have changed in several areas over the last two years. Not only am I working with more complex systems, but I need to share what I do with a lot of people as well, and in order to collaborate we need to keep the state of our work in sync.
In short - what’s needed for this to work is a content management system. While there is nothing special about that, the system that I'm getting to know is better and more available than most of the other systems out there.
I am talking about Git. Now some might arrest me for calling it a CMS, so I'll quickly correct myself by stating that it is a revision control system. Regardless of that I thought it was a pain at first when I started using it.
The fact that it mainly was designed with Linux in mind didn't exactly help a Windows guy as I am, but I've actually found quite a few quirks that make my work a lot easier. These I will come back to in later posts. For now I'll stick to describing the concept. Despite what some of my friends’ think I am not an ultra geek, thus I do not like to dive too far down into the thickest manuals and books. A lot of the material written about Git is good, but huge.
Simple descriptions on the concept itself, is not very available. (I might be a poor googler though :) ) So now I will try to explain how it works in a few bullet points. Regardless of platform you keep your work in a directory on your computer.
When you install Git in this directory, it will map the content of the directory and add this information to a ".git" directory. When Git is installed, you start working on the content. You add a few lines in a file here; you add a binary file there. Even if you save the file you are working on, Git only knows that something has changed. It does not know what you have changed, only that the files you have touched have changed.
To tell Git what to save, you commit your work. If you change two files and run the commit command Git will take a snapshot of the changes made. It will not record the state of the complete file, only the change. The snapshot receives an ID called a SHA1, and it represents a point in history and the state of the work at this point. As the number of these commits grows, and the content is changed by many different people, the changes are applied in the correct order dispensing only the changes in the content up until the last point synced.
There are numerous ways of illustrating this, but I will try doing it as simple as possible. We have users Jane and Jo. They are working on the same web site, and are using Git to synchronize their work. Both Jane and Jo started with the same directory. They cloned this directory of the server, and started working at point A. Jane made three commits. That means that she changed the content several times, and run the commit command three times. Jo did his work in two commits. All in all, we have five registered changes in the system. Git is oblivious about any work that they have not committed yet. The only thing that matters is the work that is committed.
The time line is like this: Jane committed changes at points A, B and F. Jo committed changes at points C and D. Now comes the tricky part. To be able to keep their local versions in sync with the repository, they need to pull down the changes from the repository. That means that if they did not pull down the changes in the order that they appeared, their local versions would be old.
Let’s say that Jo pulled down Jane’s changes at point A. That means that the version he started working on had everything up until point A. He then started working on the changes that eventually would turn out to be points C and D. In the meantime Jane committed point B. At point A Jane worked on foo.html. This change is reflected in Jo's local repository. Now, at point C Jo also changed foo.html. This change was based on the state of the repository at point A. However, Jane also made some more changes to foo.html at point B. This means that When Jo wants to push his changes back to the repository after committing at point D; his version does not contain Jane's changes at point B.
These changes have to be merged into his local repository before he can push his own changes on to the server. If the changes made in commit B and C does not overlap and conflict, the merge will happen and Jo can push the changes to the server. If there is a conflict between the changes, Git will complain and he will have to choose which version to use.
Tricky? Well, it probably is. Just consider yourself blessed that Git usually are able to solve most problems and merges if the people using it follow good procedures. I will follow up on this post with small (yes, small) posts on how to use Git in more detail. However, I will finish up this one with a famous quote; "If I had more time, I would have written less." #foo
Cheers, Morten
The fact that it mainly was designed with Linux in mind didn't exactly help a Windows guy as I am, but I've actually found quite a few quirks that make my work a lot easier. These I will come back to in later posts. For now I'll stick to describing the concept. Despite what some of my friends’ think I am not an ultra geek, thus I do not like to dive too far down into the thickest manuals and books. A lot of the material written about Git is good, but huge.
Simple descriptions on the concept itself, is not very available. (I might be a poor googler though :) ) So now I will try to explain how it works in a few bullet points. Regardless of platform you keep your work in a directory on your computer.
When you install Git in this directory, it will map the content of the directory and add this information to a ".git" directory. When Git is installed, you start working on the content. You add a few lines in a file here; you add a binary file there. Even if you save the file you are working on, Git only knows that something has changed. It does not know what you have changed, only that the files you have touched have changed.
To tell Git what to save, you commit your work. If you change two files and run the commit command Git will take a snapshot of the changes made. It will not record the state of the complete file, only the change. The snapshot receives an ID called a SHA1, and it represents a point in history and the state of the work at this point. As the number of these commits grows, and the content is changed by many different people, the changes are applied in the correct order dispensing only the changes in the content up until the last point synced.
There are numerous ways of illustrating this, but I will try doing it as simple as possible. We have users Jane and Jo. They are working on the same web site, and are using Git to synchronize their work. Both Jane and Jo started with the same directory. They cloned this directory of the server, and started working at point A. Jane made three commits. That means that she changed the content several times, and run the commit command three times. Jo did his work in two commits. All in all, we have five registered changes in the system. Git is oblivious about any work that they have not committed yet. The only thing that matters is the work that is committed.
The time line is like this: Jane committed changes at points A, B and F. Jo committed changes at points C and D. Now comes the tricky part. To be able to keep their local versions in sync with the repository, they need to pull down the changes from the repository. That means that if they did not pull down the changes in the order that they appeared, their local versions would be old.
A (Jane) ----- B (Jane) ---------------E (combined) ------ F (Jane) ------ \ / ------ C (Jo) ------ D(Jo) ----B/C/D(merge)
Let’s say that Jo pulled down Jane’s changes at point A. That means that the version he started working on had everything up until point A. He then started working on the changes that eventually would turn out to be points C and D. In the meantime Jane committed point B. At point A Jane worked on foo.html. This change is reflected in Jo's local repository. Now, at point C Jo also changed foo.html. This change was based on the state of the repository at point A. However, Jane also made some more changes to foo.html at point B. This means that When Jo wants to push his changes back to the repository after committing at point D; his version does not contain Jane's changes at point B.
These changes have to be merged into his local repository before he can push his own changes on to the server. If the changes made in commit B and C does not overlap and conflict, the merge will happen and Jo can push the changes to the server. If there is a conflict between the changes, Git will complain and he will have to choose which version to use.
Tricky? Well, it probably is. Just consider yourself blessed that Git usually are able to solve most problems and merges if the people using it follow good procedures. I will follow up on this post with small (yes, small) posts on how to use Git in more detail. However, I will finish up this one with a famous quote; "If I had more time, I would have written less." #foo
Cheers, Morten
Comments
Post a Comment