Git Commands and Flow


Published: 2019-01-25
Updated: 2020-05-13
Web: https://fritzthecat-blog.blogspot.com/2019/01/git-commands-and-flow.html


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.

  1. 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

  2. Two kinds of temporary mortal branches exist: feature-xxx, hotfix-xxx,
    the first for long-lasting work, the second for small corrections

  3. 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:

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.

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.





ɔ⃝ Fritz Ritzberger, 2019-01-25