Version Control
If you know the basics of git, please feel free to skip this chapter. This is for only those who do not know git.
Version control systems are used to keep track of the code changes being done. They can be used in any place which requires to keep track of changes, this book is written in markdown, using git to store tracking information and it is uploaded on github.
We will be using git
in this chapter, the concepts are same for other version control systems, just the syntaxes might differ.
Using git
Init
We call each project a repository. We first need to initialize a git repository.
This command will create an empty git repository in the current folder you are in. Ideally, this is the root folder of your project, unless your requirement is different.
Stage changes
Create an empty file and write something into it.
Add the file to the git repo, so git knows that it should track it.
We can stage as many files we want, in this step, but the recommended things is to stage and commit one change at a time. Suppose I add a new feature of notifications, I'll make only those changes and commit all the files related only to that change. Because, in future if we want to rollback to the original repo, we'd rollback to the previous commit. As a consequence to this usage, we have an awful number of commits to the repo, but that's fine, since it doesn't matter. Better software managment is what matters.
When we add files to the git repo, the file is staged.
Commit
When we commit
, we tell git to finalize
the changes, it creates a unique hash to point to this time i.e. the files which we changed. Commit messages should be short and meaningful.
Checkout
This unstages all the changes made to this file before the last commit. Use this with caution because it'll remove all the file changes.
Log
This prints a log of all commits made to the repo.
Diff
diff will show the changes made to the file as compared to the file's contents of the last commit.
Branching
While working on a team project, we are using the same codebase (on the server) with local repos on our individual machines. Adding a new feature to the master
branch is a bad way of writing code, because if our change fails and we push the changes to the remote server, we make the server's version fail as well. This is why, branching is a good way to write code.
Create a new branch per feature.
Make changes to the branch.
Submit a pull request.
Merge the branch only if everything works fine.
By default the branch is master.
Creates a new branch.
The branch in use is still the master.
Now the branch being used is the new-feature.
Going forwards, all the changes would be made to the new-feature repository.
Remote
Push and Pull
If you want to push your changes to the remote server, do a
Origin
is the remote repo and master
is the branch name which you want to push the commits to.
This book isn't about git, there already is an amazing book on git.
Gitignore
At times in a project we want a few files to be not tracked, such files are placed in the .gitignore
file in the root of the git repository. Any file or file pattern which is present in .gitignore
is ignored by Git.
Links
Last updated