Visualized Git practices for team: branch, merge, rebase

I agree with the author that learning and becoming handy with git cli is very important.<p>I don't agree that you should stop using a GUI for git, especially if you've already cut your teeth on the command line. Tower, a git GUI for Mac OS X, has a great interface and ties in very well with the core git functionality. I've learned a lot about stashing, merge conflict resolution, and cherry-picking, thanks to that app. Also, Tower shows a tree graph, similar to the network diagram the author "seriously cannot live without."<p>Why knock visual tools when when you rely on them so much?

Isn't it a little ambitious to call yourself a veteran $foo programmer when you've been doing it for a little over a year?<p>Particularly when the blog post before this is discussing how .m and .h files totally confused you. God help him if he gets asked a linked list question in an interview.

The OP gives his own definition for rebase: git rebasing is taking all your local changes since the last push and put them ahead of other people’s changes regardless of the date you made the commit.<p>But fails to explain _why_ you'd want to do that. Can anyone fill in that why for me?

I think the best thing I did for my team is explain them how branches work, and how not-so-special are they, branches are just pointers to a commit, and commits are never 'lost'.<p>People need to understand how simple Git is.

Its opposite for us. At work, we dont use branch, only git pull --rebase on master. Any idea on when and why to use branches often ?

Can somebody explain how rebasing affects shared histories. Say I'm rebasing a feature branch that's shared via github, will rewriting the commit history prevent me from pushing?<p>I avoid `git commit --amend` because of that, and thought that `rebase` had the same problem. So for that reason, I always use `merge`. Am I mistaken?

I love git. It helps me to wake up in the morning some days. But...<p>The OP's attempt to visualize git concepts falls quite short. This same old branching graph does little to nothing to illustrate these concepts. I cannot tell you how many friends and colleagues threw up their hands when someone tries to graph it out these way.

The merge-often strategy that the OP recommend in his post is the one that is Linus abhors so much. He even calls it "unholy mess" : <a href="https://lkml.org/lkml/2012/1/10/267" rel="nofollow">https://lkml.org/lkml/2012/1/10/267</a>. Basically that merge strategy can produce pointless merges.<p>See this discussion: <a href="http://git.661346.n2.nabble.com/Re-Regulator-updates-for-3-3-td7174179.html" rel="nofollow">http://git.661346.n2.nabble.com/Re-Regulator-updates-for-3-3...</a> on the git developer mailing list for more details on why that merging strategy is not liked.

His opinions on not rebasing onto master and instead merging are his own. Personally I find merging far more confusing in terms of understanding history graphs and always rebase before issuing a pull request. I think you will find that generally a lot of open source projects on Github have this practice of asking people to "please rebase your changes onto master so I can merge".<p>One practical reason is when doing bisects.<p>There are certainly two schools of thought on this, but "this is confusing to me so don't do it" shouldn't be considered a valid opinion.