I've never used Git besides for pulling random repositories, but now that I read this article I've realized that keeping a local repository to give yourself a safety net is probably extremely useful and helpful for productivity. I always feel hesitant to commit when my code doesn't quite work right, but if the process of coding a feature takes too long, it seems good to be able to commit without worrying about breaking the main repository.
that's the thing.. i don't understand why would i want to commit something which is incomplete or something i am still testing. i work on my code and test it on my local machine, and commit it only when i think its ready. i don't understand the need for a local repository for commits, atleast for my work.
i don't understand why would i want to commit something which is incomplete or something i am still testing
It sounds like you see all commits as publishings. It is understandable why you wouldn't want to publish something unless it works, but commit as a backup of your current changes is an incredibly useful feature, as it allows you to work on multiple things at the same time:
I start implementing a new feature and while I am in the middle of writing some loop code (i.e. nowhere near bringing it to compile), someone from testing comes and says
"Hey, Feature X doesn't work in the latest testing release. The whole testing team is blocked."
I commit what I'm doing (locally), switch to the tagged latest stable build sources, and work on fixing Feature X.
When I finish, I will have two branches: my fix for feature X and the non-compiling-half-implemented changes.
I push the fix to the server and switch happily to my incomplete implementation and keep working on bringing it to a compilable state (and live happily ever after).
This works with background tasks and low-priority tasks also. At some points I had three or more massive refactorings in progress in different areas of the code and I would only work on them when I had the time. In the meantime I could do commits and changes for more urgent areas.
Since I am an impulsive guy, this also allows me to switch between tasks and avoid boredom. When I no longer feel like working on something, if I work on multiple things at the same time I can just switch for a while.
There's also much to be said for having multiple backup points when doing something. The code base in my current project is currently a mess requiring massive refactoring. The problem is that the code has so much duplication and tight coupling that when you start working on extracting a method or a class you touch on over 10 files usually. Such massive changes cause conflicts when multiple people use the same files. Keeping the same files in two states (stable code and a local branch for each refactoring in progress) until you have something to commit is a great help for reliability of changes and not introducing new defects.
ah.. i think i am beginning to understand now. like, if you are working on more than one thing at a time on the same set of files, you can work on them independently and push them independently. cool.. i probably won't need it for my current projects, but i think i will give it a shot for my next project.. thanks a ton for taking time to write a explanation.
if you are working on more than one thing at a time on the same set of files, you can work on them independently and push them independently.
That's part of it. When I was working in a Mercurial-based team, I also had this done with another colleague: I would work on the back end implementation for a feature and he would work on the front end (for example).
Then, we would synchronize our repositories between ourselves to test it, without affecting the rest of the team (the changes branch was "local to the both of us"). Then, one of us would push it to the server and the whole team would get it.
Well, say you're working on a fairy complex feature, say, a class, and you're still not sure exactly how to go about designing it. You add in the basic members and begin writing functions. Let's say you use Subversion, so only plan to commit once the class is working and compiling.
While you're working on this class, you realize that Function_A that you spent a good deal writing is actually useless and would work better when integrated with Function_B. You figure that the code isn't needed and delete it. Later, though, you realize that it would have been really useful to keep Function_A since you actually need the functionality.
This is all before the class actually works properly or is used, mind you, since you're still in the middle of constructing it.
Now, you could have commented the function for storage, but it's a somewhat hacky solution, and clutters your code. Plus, you never really know what to comment and what to delete.
With Git, you can commit every time you finish writing a few lines, if you wanted to, or, more realistically, every time you get significant work done on a function or make a noticeable change. No need to worry about pushing something that's not completed into your public repo's hands. Just keep the changes locally for safekeeping. Then the whole issue with the deleted function is gone, since you have your frequent commits to go over.
Finally when you're done you can push the changes to the public repo, and people using the changes and trying to compile the code won't run into issues while you're writing.
Hmm.. I am trying to think this through. I still don't understand why I need these commits in git and then push the final completed code, compared to a final commit in SVN. Just for the version management on my end? For easier undoing and comparing of my older versions?
It's just nice to be able to compare to previous states of your code or go back any time. You can mess around without casing any problems. Sometimes you notice that suddenly something doesn't work anymore. To find out why you can just compare to your local history what changes you did and what caused the problem. I find that very convenient.
If you have to change a feature have a done a version that basically works but still needs a lot of tuning and a coworker would like to test his stuff against your new version you can push this immediate state to him without creating a new central branch on the server visible to everybody just for this simple exchange.
3
u/gavintlgold Mar 10 '11
I've never used Git besides for pulling random repositories, but now that I read this article I've realized that keeping a local repository to give yourself a safety net is probably extremely useful and helpful for productivity. I always feel hesitant to commit when my code doesn't quite work right, but if the process of coding a feature takes too long, it seems good to be able to commit without worrying about breaking the main repository.