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.
Basics
For all commands shown here (except clone) you need to stand in the root directory of your local git-project.
Participate in a 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).
Commit to Remote
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).
Update from Remote
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!
What is a Pull Request?
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.
Frequent Commands
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
Collaborative Work
Following commands resemble Vincent Driessen's Git-Flow.
-
Two immortal branches exist: master and develop, from which
master is the best, you can always branch and release from master, and
develop is more advanced, but may be unstable, anyway it is the release-candidate -
Two kinds of temporary mortal branches exist: feature-xxx, hotfix-xxx,
the first for long-lasting work, the second for small corrections -
More and more from time to time created immortal branches will exist:
release-X.X.X.
During release, bugfixes are done directly on the release-X.X.X branch, without further branching. Finally it is merged into master and develop. Release-branches are immortal because they could be deployed at customers that don't want to upgrade, but are reporting bugs.
This is the flow for hotfixes:
- branched from master
- get merged into master via pull request (to enable quality assurance)
- every fix increases the 3rd version number (semantic versioning)
- must be merged into develop when pull request was accepted
- in case a release is running, fixes also must be merged into the release branch
- fix branches get deleted after all
And this is the flow for features and releases:
- features are branched from develop
- get merged back into develop
- release is branched from develop when features need to be deployed
- features not being in develop at that time won't be released
- release gets fixed, without branching, until quality assurance agrees
- fully tested release branch gets merged into master and develop
- every feature release increases the 2nd version number (semantic versioning)
- all released feature branches and their release branch get deleted after merge
In following, please replace branch-name with a human-readable identifier that designates the issue you are solving with this branch.
Start Feature
git checkout develop git pull origin develop git checkout -b branch-name
Finish Feature
git commit -am "Write a comment here"
git checkout develop
git pull origin develop
git merge --no-ff branch-name
git push origin develop
Start Hotfix
git checkout master git pull origin master git checkout -b branch-name
Finish Hotfix of Version 1.0.0
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
Start Release Branch off 1.0.23
git checkout develop git pull origin develop git checkout -b release-1.1.0 git push origin release-1.1.0
Bugfix Release Branch
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
Finish Release Branch to 1.1.0
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
Resume
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.
Keine Kommentare:
Kommentar veröffentlichen