Hi,
Today I want to talk about the software development process and version control specifically. This feature is also useful for systems engineers who are writing shell scripts.
Experience level: Beginner.
Back in time, computer programs used to be smaller and easier. For example, the web application development process could include a single file for each web-page, being a mixture of HTML and PHP code interwoven together.
As you can imagine, the readability of such a project was a nightmare. The bigger the project, the worse. And implementing changes was a challenging task. At some point, such a project was becoming unmanageable even for a single person.
Now imagine the project was big enough to have a few maintainers, a whole group. How did they suppose to coordinate their efforts? To help to address this problem version control tools emerged (sometimes you can meet the name revision-control, which is basically the same).
One of the coziest tools (and one of the most well-known) is Git.
“Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals”.
( https://www.openhub.net/p/git/ )
Git is a command-line open-source tool, maintained by the community. Today Git has versions for Windows, Linux/Unix, Mac OS X.
It makes possible to coordinate a few contributors’ efforts being working on the same project. To control the workflow, and to roll back in time to every critical point.
It allows to split the project to several branches like development branch, production branch, experimental branch, and any other you can possibly need to effectively maintain your development process.
Git allows you to exchange your work in two ways: either peer-to-peer or more convenient way is to use a remote repository, like github.com, gitlab.com, bitbucket.org, etc.
This article is going to concentrate on such a useful feature of Git like branching.
Imagine a situation, when you are a part of a group working on a big project, continuously developing some piece of software. Your app is already up and running and has quite a few happy customers.
One day you came up with an experimental feature that could significantly influence the app’s logic, simultaneously making a lot easier some processes your customers have been using on a daily basis.
Worth it a try? I say, yes! But messing with the logic can lead to unpredictable consequences. In this case, Git will give us a hand. Here is some visualization of the process.
Simply put, every time you or your college want to place a change in the project, you are creating a snapshot of your code in its current state (called commit in Git) and upload it to the remote repository (share the result of your work: written and tested piece of code). When you want to test something, you can branch your current master, perform experimental improvements, test it, and merge with master if everything works as expected. Not a rocket science, as you can see (:
Here go some Git CLI commands if you want to give it a try:
$ git config -- global user.name “John Doe” global Git variable necessary for your identification
$ git config -- global user.email “[email protected]” global Git variable necessary for your identification
$ git config -- list see the list of the defined Git global variables on the system
$ mkdir aproject create a folder for an empty project
~/aproject$ git init and initialize it (this and all further manipulations occur in the project’s folder)
~/aproject$ touch .gitignore this hidden file will contain a list of files you do not want to share (cache, some pictures, notes, etc)
~/aproject$ git add . ask Git to track all files in the folder, including the .gitignore file. If you want to exclude it use git add * command instead
~/aproject$ git commit -m "Initial Commit" after you’ve done some changes, tested them, and ready to add them to the project (so other contributors could see them) use this command. Simply put, it is like a snapshot of changes you’ve made so far (it called commit) -m option attaches a message to your commit for identification.
NOTICE! git add . command should be executed every time before you want to commit your changes
~/aproject$ git diff a useful command to see the changes made to the project since last commit (and before the next one)
~/aproject$ git branch experimental-feature create a copy of the master branch (all other manipulations with this branch will not affect your master branch)
~/aproject$ git checkout experimental-feature switch current working branch from master to experimental-feature branch
NOTICE! It is crucial to understand what branch you are working with at the moment. Otherwise, some harm can be done. To check the branch you are currently on, use git status command
After necessary changes had been made, tested, and ready to go to the main branch, we can merge both branches.
~/aproject$ git checkout master switch back to master branch
~/aproject$ git merge experimental-feature -m "Merge merge your master branch with the experimental-feature branch after you’ve tested everything and ready to apply your changes to the main project. -m option attaches a message to your commit for identification
Congratulations! You have implemented your new feature without affecting the master branch.
Some other useful commands:
$ git log see all the changes to the project
$ git --help provide a list of possible command options
$ git option --help provide instructions on how to use exact option (do not forget to put the real option name instead, pull for example)
Additional documentation is available here: https://git-scm.com/doc
