Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Jonathan Grieve
Treehouse Moderator 91,253 PointsGit. Is it for me?
Hello all.
I know I've asked a similar question like this in the past. It concerns Git and using it regularly in my workflow.
The thing is; I don't. I have tried to get into habit of using it. It's not that I don't know the very basic commands in getting around the system. I have Git fully set up on my computer?
The fact is I've worked many many years blissfully unaware that Git even existed until last year when I tried the course for the first time. I can't but feel like I don't really need to use it. I get around just fine using my Windows explorer to manage my files. I don't mean this in a snobbish way, at the moment I just find life easier without it.
But then, Treehouse clearly swears by it as a skill that every web designer of developer should possess.
I find I struggle with a couple of concepts like handling version conflicts in a file or even how to actually push files to GitHub. I've got lucky with that a couple of times but I'm just not 100% comfortable on it.
So I need converting :) Is if suitable for a sole practitioner such as myself? Who works on simple web projects. Is Git for me?
Cheers
2 Answers
Kristopher Van Sant
Courses Plus Student 18,830 PointsI think this is a great question and I some time wonder this myself. In short yes I think Git is for you! I personally enjoy using Git and Github for my projects, no matter how small, because it helps me stay organized. Git has also become the industry standard for version control, so if you decide to join a company or collaborate with others in the future you'll already be comfortable with it. I've gathered a few links to articles and posts about this that can explain why it's beneficial for solo practitioners.
"Using git with your projects gives you several immediate benefits:
- A complete history of your project from beginning to end
- The ability to revert to any previous state or see the differences between states
- Valuable experience with a popular, industry standard tool
- Free, online cloud storage for your code" - http://sdlambert.github.io/2015/04/09/git-workflow-for-solo-development/
"Why does this even matter? Well, one of the most annoying and time-consuming experiences a developer can have is to realize that something that used to work no longer does. In such situations, simply being able to see changes and go back to an earlier version can be a huge help. Also, being able to go back gives you freedom to experiment with a new approach — there’s no problem experimenting because you can always go back." - http://www.garyrobinson.net/2014/10/git-in-two-minutes-for-a-solo-developer.html
http://programmers.stackexchange.com/questions/129407/best-version-control-habits-for-solo-developer
http://caffeinecreations.ca/blog/git-workflow
http://wern-ancheta.com/blog/2013/08/25/how-i-use-git-as-a-solo-developer/
Chris Freeman
Treehouse Moderator 68,457 PointsJonathan, to follow Kristopher's answer, I would strongly recommend picking up git. Many of my projects are solo development and I can no longer imagine working without git. The ease that git allows you to create branches and move among them is a huge feature. It's trivial to have a "master", "dev", "feature", and many, many "what if" branches.
To turn the argument around, instead of being concerned about rolling back to a previous version when something goes wrong, git allows you to proactively create a new branch at each exploratory turn. Then when you are confident with the changes, the related branches can be merged. If the code doesn't pan out, it can easily be abandon without affecting the rest of the code base. (there are way to prune dead branches easily, if desired).
I use "master" branch for release versions, "dev" for development, "feature branches" off of "dev" for each new development focus, and many "temp" branches off of feature branches to work out nuances. With this workflow, I am never concerned about writing bad code since previous work is protected on other branches.
"Branch early, branch often" is my motto.
Git is integrated into many IDE and text editors making the workflow seemless. A good git commandline and GUI tools exist for inspection of your revision history.
Jonathan Grieve
Treehouse Moderator 91,253 PointsThanks Chris.
Let me come at this from another angle. One thing that also confuses me about Git as how exactly changes are made directly in Git. I'm not talking about Git commands. I've seen videos and demonstrations of Git in which simple text files are created in Git for demonstration purposes. I see this for text files, html files and php files.. but again, I just sort this out in the usual way with my Windows OS. Is there a difference?
I'm also set in my ways when it comes to text editors. I use notepad++ which works perfectly fine with text editors. But i'm curious as to what you mean by "integrated". :-)
Chris Freeman
Treehouse Moderator 68,457 PointsNot sure if I understand your first question on "how exactly changes are made directly in Git." I would say that changes are made with git at all. Rather git tracks the revisions of files. When a new file is committed, git creates a copy of the file hidden with the .git directory. When different branches checked out git uses a system of file pointers to quickly expose the different versions. But all that is hidden for a good reason: It's very complicated under the hood. I rarely go into the .git directory, mostly for config debug, but never for direct manipulation of file versions.
A commit in git is essentially a "contour of file revisions". A project with many files each with many revisions quickly becomes unmanageable when trying to keep track of which revisions go together. The commits and branches are basically a hierarchy of contour histories. With a few simple commands, one can jump to any contour and get a complete matching set. Trying to accomplish this manually in the OS is possible but extremely difficult.
As for git integration, some text editors have built-in commands to checkout and diff files from a git repository. I use Emacs for my editing. I like being able to do a quick check on what has change in a file since the last commit. There are heavier weight IDEs like Sublime, Eclipse that also understand checkout and commits for git within the program. Git functionality for editors and IDE are usually part of some plug-in or extension that users can download and add to their environment. However, even with git integration, I still due most of my git work on the command line.
Jonathan Grieve
Treehouse Moderator 91,253 PointsYour reaction suggests what I'm thinking of isn't a proper industry practice then. :)
Let me see if I can pick out the video I'm thinking of.
Here's one. In this video in the Git Basics course, Tommy starts to use Git to go into a file by using
nano name_of_file around 2 minutes 50 seconds in
It goes into a new window in the console to edit the file directly. He starts typing some text, saves it and makes a commit on it. But don't we achieve the same thing by simply making our changes on our PC or MAC outside of git? What kind of files can we save the other way>?
I see it more like using Sass. You track changes in the console and let it do the work behind the scenes. Using Nano always confused me though and i never saw the benefits.
Chris Freeman
Treehouse Moderator 68,457 PointsThe editing of the file with nano is not part of git. It's just a convenient way to edit the file for the workspaces. Any editor can be used even NPP. So at this point we just have files and directories that have changed. All outside of git.
Git comes in when we want to snapshot current versions using git add and git commit. Git then inspects the directories and files through normal OS access to see what has changed since the last commit. In a normal add-commit progression, git does not alter any files it just makes detailed reference notes and copies of files for its own use. Only when git is used to switch between branches or check out previous versions does git then overwrite files with the requested versions.
Having lived through RCS, CVS,
Visual SourceSafe, Subversion, and Mercurial version control systems, I enjoy using git above all others.
I encourage you to continue learning git and explore the links Kristopher posted above.
Jonathan Grieve
Treehouse Moderator 91,253 PointsI will get to those links I promise you Chris Freeman and Kristopher Van Sant. I meant to today but I've been sidetracked with Wordpress stuff :)
Thanks for your feedback with Git. I understand your last comments (i think lol) and I'm looking forward to researching more. Maybe one day Git will become a bigger part of my worflow.
Jonathan Grieve
Treehouse Moderator 91,253 PointsJonathan Grieve
Treehouse Moderator 91,253 PointsWow :)
You've given me a lot to read there, thanks for your thoughts and I'll let you know what I make of them.
Chris Freeman
Treehouse Moderator 68,457 PointsChris Freeman
Treehouse Moderator 68,457 Points+1
Nicely done. Kristopher! A lot of good information here.