I keep getting questions from people who are just starting to learn how to code. No matter what their scenario is, what languages/frameworks they want to learn, one piece of advice always remains constant: Create a GitHub/Bitbucket account, learn Git, and push code every single day.
Ever since version control systems such as Git have become widely-known and well-used, modern development processes have radically changed. Git has turned out to be one of the leading Version Control System in today’s time.
Git is the most commonly used version control system. Git tracks the changes you make to files, so you have a record of what has been done, and you can revert to specific versions should you ever need to. Git also makes collaboration easier, allowing changes by multiple people to all be merged into one source.
So regardless of whether you write code that only you will see, or work as part of a team, Git will be useful for you.
Git is software that runs locally. Your files and their history are stored on your computer. You can also use online hosts (such as GitHub or Bitbucket) to store a copy of the files and their revision history. Having a centrally located place where you can upload your changes and download changes from others, enable you to collaborate more easily with other developers. Git can automatically merge the changes, so two people can even work on different parts of the same file and later merge those changes without loosing each other’s work.
Git was developed by Linus Torvalds, creator of Linux Operating System. Git was developed when the relationship between the existing Version Control System (BitKeeper) and Linux team broke.
Version control makes collaboration in a team easier. Without a version control system, everybody on the team is probably working on the same shared set of files. It’s only a matter of time until someone overwrites someone else’s changes.
Also, a VCS takes care of combining changes from different people into one common version. In version control nomenclature, this is called merging. As a result, working on the same files simultaneously becomes safe and easy.
But even when you’re working on your own, a VCS still has plenty of benefits.
For example, version control makes storing and restoring versions of your project a lot easier.
Without a VCS, you’re probably saving versions of your files and folders using your own adventurous naming scheme.
With a VCS in place, you only have a single project folder on your disk. All other versions and variants are safely stored in your version control system’s database, neatly described, and ready to be restored any time you want them.
Last but not least, one of the best aspects about using a VCS is that it serves as documentation, and also helps promote the act of documentation.
Since each major change is wrapped in a commit (more about this term later), and each commit is described with a message, you can very easily follow along and understand the incremental changes in a project. This becomes even more useful when problems arise and you have to find out where they originated.
Git was built for the Linux kernel, but supports other platforms. Head over to git-scm.com for download and install instructions. Most major IDEs and code editors have Git integration, making the git command line optional.
Git is open sourced under the GNU General Public License version 2. All the code is up on github. Not all the tools and integrations are free, but since I’m a command line junky, everything I need is free.
Git was built from the ground up to scale, both in terms of number of participant and branches, as well as overall repository size. The classic example of a huge git-based project is the Linux kernel, which has thousands of contributors, thousands of commits, a the packed size of the current repository is over 100MB. Nothing that I’m working on can come close to those numbers, but it’s nice to know there’s room to grow.
Distributed version control systems like Git, Mercurial, and Bazaar have a clear advantage over their centralized counterparts: they allow users to work offline and continue committing to the repository in parallel to other developers, without getting blocked on acceptance of your commits. Even if you’re not stuck at the airport trying to write code, why tie any commands to network access and latency? Git puts your entire repository (history and all) at your fingertips.
As an example of when this helped us: A couple of years ago, one of our clients was hosting their repository privately on Github. Github went down for a big chunk of the day. Developers at AO were still able to share code and commits via a nice tool called bananajour. Once Github came back up, we could easily push our changes as if nothing ever happened.
Coming from an SVN background, the real beauty of Git is how it handles branches. We tend to work mostly on master, but anything that will not be finished by end of day generally gets moved to a separate branch. We keep master in a deployable state using branches for larger features or spikes. Git allows us to easily share branches, keep them up to date, and merge them back into master.
Along these same lines, git stash is amazing. It allows you to push your current changes onto a local stack to be popped off when convenient. You could accomplish the same thing with branches, but stashing doesn’t force you to actually commit any “in-progress” work.
Git handles your security with cryptographic method SHA-1. The algorithm manages your versions, files, and directory securely so that your work is not corrupted.
To understand how switching to Git affects your company’s marketing activities, imagine your development team has three distinct changes scheduled for completion in the next few weeks:
If you’re using a traditional development workflow that relies on a centralized VCS, all of these changes would probably be rolled up into a single release. Marketing can only make one announcement that focuses primarily on the game-changing feature, and the marketing potential of the other two updates is effectively ignored.
The shorter development cycle facilitated by Git makes it much easier to divide these into individual releases. This gives marketers more to talk about, more often. In the above scenario, marketing can build out three campaigns that revolve around each feature, and thus target very specific market segments.
For instance, they might prepare a big PR push for the game changing feature, a corporate blog post and newsletter blurb for Mary’s feature, and some guest posts about Rick’s underlying UX theory for sending to external design blogs. All of these activities can be synchronized with a separate release.
The benefits of Git for product management is much the same as for marketing. More frequent releases means more frequent customer feedback and faster updates in reaction to that feedback. Instead of waiting for the next release 8 weeks from now, you can push a solution out to customers as quickly as your developers can write the code.
The feature branch workflow also provides flexibility when priorities change. For instance, if you’re halfway through a release cycle and you want to postpone one feature in lieu of another time-critical one, it’s no problem. That initial feature can sit around in its own branch until engineering has time to come back to it.
This same functionality makes it easy to manage innovation projects, beta tests, and rapid prototypes as independent codebases.
Git has stepped out of being a technology for early-adopters. Today, more and more developers are using it to improve the quality of their code and workflow.
I could keep listing off reasons, but the short of it is: go try Git right now. I haven’t found anything better.
As for now, we have understood that Git is more powerful and widely used version control systems. After understanding what and why it is better to understand how to use Git.