When I first used git I hated it. So did most of the project team at the time. All of use had quite strong(ish) background in SVN and some Perforce experience. Now git was strange and difficult to use to us. If you have similar background you probably can understand the pain coming from SVN background to using git without actually studying git and how it should be used. Push pull commit what when how? Confusing it was to me.
Later on during another project I got a little hang of git. I got around the idea that I could use my local repository as I would use SVN, I commit to it. When I want to publish my changes that is when I use push and pull before I do that. I got to like git a bit. A colleague during that project showed me some tips’n’tricks to git, thank you Mr. Peränen. He showed me a working method that I really liked.
He said that he tries to do things in feature based manner. He would checkout a working branch where he would implement the feature. This branch could then be merged back to where it was checked out using the –squash option. This way it would only create one commit which would be sufficient if you were working in feature manner. What changed in the feature was contained in that single commit.
Another advance in this way of working is that you can checkout new branch which you can conveniently call merge. If your feature implementation has taken some time and if there has been a lot of changes in the development branch this can be a really good thing. You can do the merge in peace in this new branch and if the merge takes a long time you can continue the merge process to apply changes that might have come while you have been merging the code base. If the merge fails you can delete the branch and start again.
This might sound like a lot of work, but I personally found this workflow to be very handy. With this type of workflow I really got to like git. It worked for me and I have since used this method until I came across with git flow which basically gives same type of workflow. I would still like to add (or hope someone would add) a feature to git flow that it would automatically create merge branch, try the merging there when finishing a feature and finally merging the merge branch into the develop branch using –squash option. I have yet to find a reason to keep the commit history from feature branch, but maybe I will someday. As explained earlier one feature as one commit is what I like.
There was an article in Dr. Dobbs about praising small commits. I too would like to praise them. One great advantage that I see with one commit per feature is that if you need to revert the feature you can do it in a single commit. Personally I think this keeps things much cleaner and tidier.
We are currently using git flow. We are all still learning it, but as they say practice makes perfect. If you are not using git flow I suggest that you try the method described earlier that was thought to me by a colleague. Changes can take time, but if you do not even try what it would be like if you changed your methods then the change will never happen. You could as well as still use punched cards.
In a world suitable for me there would be git flow with the behaviours described that would make the commit smaller. Taking on step toward it makes things sometime easier for some people. Sometimes it feels like these changes in the way we work can be difficult and even painful, but if we see the effort the result can make our lives much easier and the time we spend doing things more efficient.
I personally think that this kind of working method is ok with a small team, like a team of three persons like the one I am currently working in. Of course this would need the agreement of the development team and cooperation of the rest of team. If others (even one) does not cooperate with the workflow then the thing might not work at all and causes more problems than it solves.
There are lot to learn about git and a lot that I have learned, but have yet utilized in my way of working. I know that the correct way to use git is that you never push, you make a pull request. This is quite good practice because you would basically need a build master or someone who keeps the commits in check. In this type of working you cannot just commit and overwrite like I have seen people do. On a side note I actually worked on this project where the project “architect” usually did commit and overwrite and each time he put something into the SVN there was a moment of hell when development team tried to fix things. This is actually the same project where Mr. Peränen thought me the niceties of git and git svn. I know that there are still people that do commits three in the night that screws up everything and then in the morning they get ignorant people to “celebrate” their “braveries” that has probably set the project a bit backwards. But back on the subject the pull request thing is very good specially in open source projects. You can review the upcoming changes before you apply them to master or development branch.
We will never live in a perfect world. There are as many opinions as there are people. But we can try to improve things. We can try to enforce people to change their ways of working by making using things correctly more easy and using them incorrectly as hard as possible. Unfortunately we are only humans, the worst species on the planet.