I used SCCS, RCS, CVS, SVN, and all these version control systems (VCS) were getting better and better over the years, especially SVN was nearly perfect in the end.
Now a tool with the beautiful name Git has come into vogue, created in 2005 by Linus Torvalds. End of 2018 it made up 61% of all VCS installations. Some say this is a big step forward, some say it is two steps back.
Using Git definitely requires more time than the old VCS, because it is much more complex. It was made to provide access to the LINUX source code for thousands of developers, not for small companies that have ten developers and never would open their source for public work. Long-termed collaboration of many people also requires a strategy, something like Vincent Driessen's Git-Flow, because it is based on branches.
In this Blog I will list some basic command sequences that may be useful for all who need to use git. For simulation of multiple user collaboration I could not find a compound try-out site on the Internet, so you would have to (patiently) install a git server on your machine when you'd like to test this.
For all commands shown here (except clone) you need to stand in the root directory of your local git-project.
git clone projectUrl
Somewhere on the web-page of the git project of your choice you will find the projectUrl you need to check-out (sorry, clone).
After cloning, your current branch is the master branch. This is something like a holy grail, and most likely you won't be able to commit to it. But assumed you can, do the following to save your changes to the project:
git commit -am "Write some check-in comment here."
git push origin master
The commit command just saves into you local git store. The -am option is an abbreviation for -a -m, whereby the -a ("add") will cause all newly created files to be added (staged), and the -m ("message") is the opener for a comment text. If you dropped the -a, you'd have to launch a "git add ." before the commit, standing in the project's root directory.
What was commit in old VCS is now push. The parameter origin is a git-convention designating the remote repository (URL) where the project came from. The name of the branch that will be updated is master.
After this, your colleagues will be able to see your changes as soon as they update their project-clone (that is also on branch master).
git fetch
This updates your local git (not your source code!) with knowledge about e.g. new branches on the repository. This is not always needed, but sometimes you should do it.
git pull origin master
You "pull" changes from the remote project's master branch and merge them into your (possibly modified) sources. Conflicts can occur.
→ Mind that it is very recommendable to update (sorry, pull) your sources before you commit (sorry, push) your changes!
As you mostly can not push to master branch, you ask someone having permission to do it.
Launch a browser and go to the web-page of the remote repository. Choose your branch. Find the button to open a pull request. Fill out the form and submit.
git status # displays local changes
git branch # lists all branches known locally
git checkout branch-name # changes from current to named branch
git checkout -b new-branch-name # creates a new branch and makes it the current one
git merge branch-to-merge # merge another branch into current branch
# delete a branch from local and remote
git branch -d branch-name
git push origin --delete branch-name
git reset --hard HEAD # dismiss all local changes and commits and replace everything with remote sources, use any hash-id from 'git log' instead of HEAD
Following commands resemble Vincent Driessen's Git-Flow.
This is the flow for hotfixes:
And this is the flow for features and releases:
In following, please replace branch-name with a human-readable identifier that designates the issue you are solving with this branch.
git checkout develop
git pull origin develop
git checkout -b branch-name
git commit -am "Write a comment here"
git checkout develop
git pull origin develop
git merge --no-ff branch-name
git push origin develop
git checkout master
git pull origin master
git checkout -b branch-name
git commit -am "Write a comment here"
git checkout master
git pull origin master
git merge --no-ff branch-name
git tag -am "Write a comment here" 1.0.1
git push origin develop
git push --tags origin develop
git checkout develop
git pull origin develop
git merge --no-ff branch-name
git push origin develop
git checkout develop
git pull origin develop
git checkout -b release-1.1.0
git push origin release-1.1.0
git checkout release-1.1.0
Change sources, then do:
git commit -am "Explanation of bugfix"
git push origin release-1.1.0
git checkout develop
git pull origin develop
git merge --no-ff release-1.1.0
git push origin develop
git checkout master
git pull origin master
git merge --no-ff release-1.1.0
git tag -am "Explanation of release" 1.1.0
git push origin master
git push --tags origin master
git checkout develop
git pull origin develop
git merge --no-ff release-1.1.0
git push origin develop
For collaborative work inside a protected domain, where everybody frequently updates and commits sources, SVN would be the better system, because it is much simpler than git.
For development that is done across the world in long-lasting tasks, git would prevail.
So make you choice. There won't come anything any more after git.
ɔ⃝ Fritz Ritzberger, 2019-01-25
