sorted by: recent | see : popular

Content Tagged with VCS + subversion

Now, how do you get any new changes from a remote repository? You fetch them: git fetch. At this point they are in your repository and you can examine them using git log origin (git log HEAD..origin to see just the changes you don't have in your branch), diff them, and obviously, merge them - just do git merge origin. Note that if you don't specify a branch to fetch, it will conveniently default to the tracking remote. Since you frequently just fetch + merge the tracking remote branch, there is a command to automate that:

The mr(1) command can checkout, update, or perform other actions on a set of repositories as if they were one combined respository. It supports any combination of subversion, git, cvs, mecurial, bzr and darcs repositories, and support for other revision control systems can easily be added.

But, if subversion is a team-based tool, git is designed around individual developers, loosely-connected in social groups. This distinction is what makes git an excellent social tool - an excellent choice for software developed by a diverse group of individuals as open-source projects often are. Just for the record, github rocks. However, git’s group-development virtues are team-development vices. Branching is an evil for small teams. Single-trunk development with continuous, often, easy integration leads to fewer bugs, better communication between team members, sharper code. I’d go further than most agile proponents here: if your team is small enough to handle it, this is what you should do; if it isn’t, it’s time to split the team.