If you’re using git on Ubuntu, the version distributed via apt may not be the newest version of git (I use git to deploy changes on all of the sites I manage). You can install the latest stable version of git provided by the maintainers as follows:
I was recently asked to speak about and provide insight into git at a meetup I’ve been running with a friend. As a developer, a version control system is a critical part of your toolkit, no matter the size of the project or team you may find yourself working on.
I first started learning to use git by applying it to my own projects and maintaining local repositories to track those projects. From there I moved on to hosting and storing my git repositories at Bitbucket while still working independently. My first experience with working alongside other developers in git came at my first full time development job on a small team (think really small — two developers, myself included). I picked up the basics of branching, handling merges, developing different features in parallel and, ultimately, dealing with QA and production deployments that were sourced from various branches in our project repository.
I’ve expanded on my knowledge git in the jobs I’ve held since that first position and have used svn pretty heavily as well (I don’t mind it, but I don’t love it — I’d argue git is the better choice for a number of reasons, its decentralized nature and flexibility being chief among them).
One of the many appeals of git is its flexibility and there are a wide range of commands that come with it. To get started, I’d suggest digging in with the following:
Each of these commands has numerous options associated with it and allows for broad control over the flow and history of your project. There are a number of other options I’d suggest for learning more about git:
I recently moved all of the repositories for my personal and client development projects to Bitbucket. I had been paying for Github’s micro plan to manage a few projects that I didn’t want public, but made the decision to switch after exploring a bit more and seeing that, well, Bitbucket provides the functionality I was paying Github for for free.
Making the switch itself was painless. I added a key to my Bitbucket account, switched the remotes out on my repos and pushed each repo to its new home on Bitbucket. Switching remotes out is as simple as:
git remote set-url origin REPO-URL
Github is, of course, an incredible resource but, for my purposes, the switch made too much sense not to carry out.