Git has some popular features that make it easy to rewrite the commit history, and in some cases, this is a benefit. However, these features can be unnecessarily confusing, and if used incorrectly, they can cause data loss. Read more on Modifying Your Git History? Here Are a Few Things to Think About…
Git is a fantastic tool, used by millions of people around the world. While Git GUIs can be useful tools, using git on the command line has a higher ceiling for productivity, especially when one can use aliases or refer to their own command history.
Learning Git can be overwhelming, especially if you have not had any previous experience with a version control system. Many Git tutorials begin with a few basic commands, and you can probably get by on those for most day-to-day tasks. But eventually, you’ll run into a situation that the tutorial didn’t cover (like, “Oops, I just committed to the wrong branch”).
Fortunately, a quick Google search will reveal a Stack Overflow post with a cryptic command to get the job done. And given the number of upvotes, it will probably work. But unless you understand why it worked, you’ll likely be right back there again the next time you run into a similar problem. Read more on Git – It Makes Sense Once You Understand It…
In professional software development, version control systems (VCS) are a critical part of our daily routine, because they allow developers to:
- keep an accurate record of the entire history of a project
In my experience, working with a Git repository hosted by Gitlab, Github, or Gitorious has generally been issue free and enjoyable. Recently, however, three members of my team ran across the same cryptic RPC error when trying to push changes to a remote repository on Gitlab:
error: RPC failed; result=22, HTTP code = 411
In two cases, developers were trying to push new framework libraries (they were moderately sized, 2-9 MB). In the third case, a designer was trying to push a large batch of image assets. In all cases, the problem was caused by using the HTTPS protocol with a server configuration that disallowed individual files larger than 1 MB.
After some basic investigation (thanks Stack Overflow!), we found that using the SSH protocol with Git solved the problem. This type of issue could trip up a new user of Git, so I am going to use this post to briefly describe the problem and summarize the pros/cons of using HTTPS vs. SSH protocols to talk to remote repositories.
Git is a powerful tool that we love as developers. It’s also complicated. I consider the bare essentials of Git, the minimum set of features to be familiar with before we can be productive, to be all of this:
- local interaction: status, add, remove, commit, reset, checkout
- branch management: checkout, merge
- remote interaction: clone, fetch, push, pull
Once we’ve learned these basics well, we move onto advanced features and tricks. Read more on Sharpen Your Git Saw – Aliases, Selective Staging, & Interactive Rebasing…
I recently was asked to teach a workshop at Hope College on Git. I am jealous of the students that attended. Their curriculum includes things like unit testing and version control. Having the importance of source control shown to them so early is a major boon. Giving this talk got me thinking about why I prefer Git over other version control systems like SVN, Mercurial, Perforce, etc. Read more on Why Use Git?…
Justin and I provide operational support to the SME Toolkit project, an education portal for small to medium sized enterprises in developing countries sponsored by the IFC (which is the private sector development branch of the World Bank Group).
Recently, the source code for the Rails-based web application was migrated from Subversion to Git. This also changed how we deploy the application. Previously, we deployed a snapshot of code from a tarball placed on a bastion server. With a few changes to our Capistrano configuration, we are able to deploy directly from the source code repository. Read more on Deploying from Git with Capistrano…
Occasionally, a subversion repository may start to become too large and cumbersome to work with easily. If the repository contains a large amount of data, it may take a great deal of time to perform certain operations, such as checking out the entire repository at once. It may make sense to split the repository to isolate the more frequently modified files or directories — especially if they serve different purposes.
For example, let’s say we had a repository named
repo1 with the following structure:
# in repo1 branches tags trunk trunk/project_a trunk/project_b