[Osiris]

I just recently switched to Git after joining a new company. The team I'm on was just in the process of switching from SVN to Git, so we were all spending a lot of time online in Pro Git as well as researching various workflows.

I think that we're still not fully taking advantage of Git because the other members of the team tend to commit and push all the time (so the code is backed up) but that makes rebasing and squashing quite difficult.

Git has also allowed us to work better with maintaining feature branches and bug fix branches which helps us to give individual branches to QA for test and only release those features/fixes that have been QA approved. If a feature isn't ready on time for deployment, it just doesn't get added to the integration branch and it'll go out the next release. That's pretty cool.

Personally, I've settled on using SourceTree as a GUI with a fallback to the command-line for certain operations.

[leetrout]

Do you have an anecdote about why having more commits have made rebasing / squashing difficult? Is it just that team members are pushing their numerous changes to the central repo? I'm wondering if I'm missing something because I never squash commits...

[maw]

Chances are they're pushing to the same branch or to the same small number of branches instead of to private-ish branches. This is an easy trap to fall into: lots of people have a hard time getting used to using branches for everything.

As for squashing or not, I rarely do, and in general only squash commits that are simple typo fixes. This makes bisecting much easier.

Also, and this may or may not be relevant, maybe some people are reluctant to spam the central repository with their own temporary branches. To avoid this, I have everyone in my team set up a personal, backed up repository. Anyone can pull from these personal repos, but only their owners can push to them. When the temporary branches are done, they can be merged.