Git
Version control made easy
Git is a centralized version control system. Said otherwise, it's a tool to maintain a centralized repository of code, which can have different versions. That's the software we use for all of the Prospect.io applications.
Git can run from the command line (using the git CLI) or using an interface, such as GitTower. But, whatever the way you use it, it will always rely on the same components and principles:
A git repository is made from 3 parts: your local directory, the remote repository, and your staging copy (the set of files you are working on)
Changes are grouped together in so-called "commits", that can be on different "branches". The main branch is called "master".
Code can be added to the staging area with "git add", grouped in commits with "git commit", pushed and pulled to the remote repository with "git push/pull".
Working with branches
When working in a team, it is common that we have different branches, which are holding different sets of commits, representing the different features we are building. We have:
the master branch, which is the branch holding the production code of the application
the release branch, which holds the features that are going to be released
we sometimes also have sub-branches, for parts of the features that are under construction
What if I did a mistake
One big advantage of git is that every change, every mistake can be rolled back. To remove a mistake that was done locally, use "git reset". To remove a mistake that was pushed, use git rollback. This will create another commit that cancels the previous one.
Destructive commands: Rebase, Squash, …
To be sure that we can always roll back a change, and to avoid merge conflicts when working in a team, we need to never use any destructive command. A destructive command is one that has an impact on the previous commits. Commands such as rebase, squash, rename, are thus discouraged on pushed commits. Anyway, if you wanted to run them, git would warn that you should use the --force flag in order to perform it.
There are just a few exceptions to this rule:
If you are alone working on a branch, and are sure nobody will join you on the branch
If you want to remove sensitive information that was pushed in the git repository
Useful resources
Cheat Sheet
Best Practices
Last updated
