A version control system plays a vital role in collaboration of different team & making a product successful. The purpose of this document is to demonstrate the basics of version controls with one of it tool git & provide an overview of command & set up.
Git is free & open source version control system, originally created by Linus Torvalds in 2005. Git is distributed: every developer has the full history of their code repository locally. Git has excellent support for branching, merging, and rewriting repository history, which has lead us to many innovative & powerful workflows and tools.
Basic flow of communication with version control can be following steps:
1. Clone the remote repository or create local repository.
go to your folder where you want the code to be cloned & run:
git clone remote_repository_url*
remote_repository_url: It is the remote location/cloud where source code is uploaded.
2. To add files which are modified git add . command is used.
3. To save files locally git commit command is used.
4. To merge the source code from other branches git pull is used.
5. To push source from local to remote git push is used.
Now let’s see some of the commands which are used to make changes at advanced level:
1. Git Rebase: This command is designed to integrate changes from one branch to another branch. The major benefit of rebase is that it provides us a much cleaner project history. This makes it easier to navigate your project with commands like git log, git bisect, and gitk.
Consider for example if there is a feature branch then with master rebase command will go like:
git checkout feature git rebase master
This moves the entire feature branch to begin on the tip of the master branch effectively incorporating all the new commits in master. But rebasing re-writes the project history by creating brand new commits for each commit in the original branch. If we don’t follow the rules of rebasing, re-writing project history can create issues in collaborative environment.
Git rebase additional commands:
git rebase — d: During the play back the commits will be discarded from the final combined commit block.
git rebase — p: Leaves the commits as it is.
git rebase — x: During playback executes a command line shell script on each marked commits.
2. Interactive Rebasing: It gives us the opportunity to alter commits as they moved to the new branch. This is more powerful than an automated rebase, since it offers complete control over the branch’s commit history.
To begin an interactive rebasing session, pass the i option to the git rebase command:
git checkout feature git rebase –i master
This will open a text editor listing all of the commits that are about to be moved.
Following are the options working with interactive rebase to update commits:
Reword(r): It can change the message of any commit based on commit id.
eg.: r 3ededdw I am updating message
Squash(s): It melds commit into previous one.
Fixup(f): This act like squash but discards this commits message.
eg.:
pick 07c5abd Introduce OpenPGP and teach basic usage
pick de9b1eb Fix PostChecker::Post#urls
pick 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend
The Golden Rules of Rebasing:
1. git rebase should never to be used on public branches.
2. Force push (git push — force) after master rebase should not be used if you are not sure about it.
You can use interactive rebasing for local clean up. For example, following command begins an interactive rebase of only the last 3 commits:
git checkout feature git rebase — i HEAD~3
You need to avoid git rebase after creating the pull request.
3. Amend: The git commit –amend is a convenient way to modify the most recent commit. It lets you combined staged changes with the previous commit instead of creating an entirely new commit.
git commit — amend
4. Git Cherry Pick: git cherry-pick is a powerful command that enables arbitrary Git commits to be picked by reference and appended to the current working HEAD. Cherry picking is the act of picking a commit from a branch and applying it to another.
git cherry-pick can be useful for undoing changes.
It is a useful tool but not always a best practice. Cherry picking can cause duplicate commits and many scenarios where cherry picking would work, traditional merges are preferred instead.
5. Git Ignore:
Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named .gitignore. Here is an example .gitignore file:
*.[oa]*~
The first line tells Git to ignore any files ending in “.o” or “.a” — object and archive files that may be the product of building your code. The second line tells Git to ignore all files whose names end with a tilde (~), which is used by many text editors such as Emacs to mark temporary files. You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. Setting up a .gitignore file for your new repository before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository.
The rules for the patterns you can put in the .gitignore file are as follows:
· Blank lines or lines starting with # are ignored.
· Standard glob patterns work, and will be applied recursively throughout the entire working tree.
· You can start patterns with a forward slash (/) to avoid recursivity.
· You can end patterns with a forward slash (/) to specify a directory.
· You can negate a pattern by starting it with an exclamation point (!).
Reference for study: https://git-scm.com/book/en/v2/Git-Branching-Rebasing