Welcome to the Treehouse Community
The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.
Jonathan GrieveTreehouse Moderator 90,956 Points
Git: Working with Commits
Quick question on using Git commits.
One of my favourite things about Git in my limited experience with it, is that I can go to various versions of a file, so long as I have a commit for it.
I had this idea that I could save different code snippets in different versions of a file so long as I have a commit for it, or use commits to go to a completely different CSS colour scheme if I wanted. I can see how powerful Git is.
But when I go to a commit, my main question is what do I do next? Do I simply move the commit and it's previous commits to a new branch and work with some files there? How do I get back to the latest version of the files and if I have a merge problem or anything breaks can it be fixed by simply deleting branches and going back to the master branch?
Sue Dough35,800 Points
"How do I get back to the latest version of the files?"
This will do a hard reset to the latest commit. It will throw away any uncommitted changes. Run git status to confirm after.
git reset --hard HEAD
You can create and delete branches any time. You can even delete branches permanently and still go back in time once its merged.
to create a new branch and check it out
git checkout -b myNewBranch
to view your branches
to delete a branch
git branch -d myNewBranch
If you have a merge conflict and your using for example GitHub to merge in the gui they will tell you how to fix it. The first ones the hardest but you will be alright.
And to go back to master
git checkout master
Karolin Rafalski11,368 Points
Git commits are like 'snapshots' of your project. Branches are where you create different versions of your project.
Have you ever written a term paper and made files like termpaper1, termpaper2,termpaperfinalversion, termpaperfinalfinalversion. termpaperrealfinalfinalversion? These are more similar to branches in git. And then every time you had hit 'save' would be more like 'commit'.
The reason you made all the saves was that you made some progress that you didn't want to lose due to a power failure, your laptop being stolen, etc.- these are the times you want to use commit in git.
The reason you would have made those file versions of the your term paper was probably because there were some changes that you were making that you were nervous would mess something up, or you'd want to easily go back to a previous version.
Let's say you were working on some CSS, and you were torn between a light color palette and a dark color palette, you would start with some basic css that would go in both, so you would probably create a branch called main -for the main css and html. Then from there, you could create two other branches: light and dark. You could switch between these branches as much as you like and change all the associated files, without affecting the main branch.
At some point though, you would make a choice between the css and then you would merge your branch of choice into your main branch which would be your 'final' version.
Let's say you chose the light version. You merge that. But you don't have to do anything with the dark branch. You could delete it ,if you decide you'd never use it, or you could just leave it alone. All you have to do is git add and git commit your changes and then you can switch branches.
If you get a merge conflict, you just work out the conflict: it's not so scary. Take a deep breath first, and then it'll be fine.
Sometimes you do want to go back to an old commit, and then it would be wise to create a new branch if you want to work on stuff. You typically don't want to go and change commits, since that can be like rewriting history and that can lead to many problems.
I know this sounds like a lot, but it really just is a matter of when you do it, it will make sense. At this point it is rather abstract. But it gets better. I hope this info helps.
@Jennifer - I am excited to see your work! I hope to see you at Ugliest CSS soon!
I have put Ugliest CSS live on the web: http://krafalski.github.io/ugliestcss/