Getting started with Git

• it is a software (that has to be installed on your computer)
• it allows to record snapshots of your code and to navigate, explore and compare this snapshots
• it is the very first step toward software reproductivity
• other famous VCS: Subversion (svn), Mercurial, etc.
• My personal opinion:
  • didactic tool with a very useful help messages
  • fast learning
  • small entrance ticket that worth to pay it
  • VCS should be integrated in your daily routine
  • to get used to it, commit your config scripts in a private repo ;-).

There are different ways to use git, pick your favorite one:

• at the command line with git
• inside your text editor (Magit for Emacs, Fugitive for Vim)
• with a git client (Git Extensions)
• using the web interface of the hosting platform (https://gitlab.inria.fr, https://github.com…)

Use the -h option.

git -h
git add -h

git init
git add .	      # Add all the files under the current directory.
git commit -m "This is the first commit."

git clone https://github.com/Algiane/mmg-MdB
cd mmg-MdB

What you obtain is a checkout.

• the files you edit are in the working directory
• git add adds changes to the index, which is a staging area. Run git add -p to choose interactively and step by step changes to add or not.
• git commit commits what the index contains to the history
• git status reports on changes in the WD and in the index
• git diff HEAD shows changes compared to the tip of the current branch

1. Modify multiple files or file area of your working dir
2. Choose modifs that have to be indexed using git add -p
3. Inspect your repo with git status
4. Commit your index content with git commit -m "suitable commit message"
5. Inspect your repo

• branches represent different lines of history, which can be merged:
  • Use git branch -l to list the local branches.
• the “default” branch is called master or main
• git branch <NAME> creates new branch <NAME> off the current branch
• use git checkout <BRANCH> to switch the working tree to an existing branch named <BRANCH>
• git checkout -b <NAME> create a new branch <NAME> off the current branch and automatically switch on it
• git log --graph --abbrev-commit --decorate draws branches graph and commits in your terminal

• rebasing a branch <feature> into another (<master>) means that you will move the branch <feature> on the tip of <master> (git checkout <master> && git rebase <feature> ). For each commit of <feature> a new commit is created in <master>. The project history appears linear and it is easy to navigate the project (with git log and git bisect).
• merging a branch <feature> into another (<master>) (git merge <master> && git rebase <feature> ) creates a new merge commit that ties history of both branches. It preserves the tree structure of the developments.

See the following ref for a description and comparison of both processes.

• master^<n> allows to choose between ancestors when a commit has more than one parent (see this stackoverflow discussion).

git show 4cfeba^1
git show 4cfeba^2

Exercise:

1. Create a new branch from the master one and switch to this branch (git checkout -b <branch_name>)
2. Modify the first line of the README.md file
3. Add and commit changes (git add -p, then git commit)
4. Switch to the master branch and modify the same line of the README.md file (git checkout master)
5. Add and commit changes
6. Check that both branches have diverging commits
7. Merge the new branch into the master one and solve conflicts (git merge <branch_name> then git mergetool -t meld)

Branching strategies will help you to understand your history and to limit conflict creation.

• An easy to set-up strategy is the Feature Branch Workflow :
  1. you never work directly in master branch
  2. features are developped in dedicated feature/<my-feature-name> branches and merged into master when ended
  3. multiple features can lived at the same time
• For projects with regular software releases, the Feature Workflow with Develop Branch variant can be used:
  1. you never work directly in master branch, it contains the production-ready state of the repository
  2. you have a unique develop branch deployed from the master in which you do not directly work either. The develop branch contains the latest developement changes for the next release and is merged into master when the realease is ready.
  3. features are deployed from the the develop branch in feature/<my-feature-name> branches and merged into the develop branch when ready.
  4. release fixes are deployed from the master branch into hotfix/<my-hotfix> one and merged when ready.

• Keep comments in code, not in commit log
• keep commits small and focused: you can stash away things not related to your commit
• keep branch focused: creates new branches to separate tasks when a task leads to unexpected developments. You can use the git cherry-pick command to copy a given commit from one branch into another one (if needed) and limit conflicts.

• crunchbang refcard
• Danny Adams refcard

• some git workflows: https://rovitpm.com/5-git-workflows-to-improve-development/
• focus on git flow workflow (in french): https://blog.engineering.publicissapient.fr/2018/03/28/gitflow-est-il-le-workflow-dont-jai-besoin/
• git branching naming convention: https://codingsight.com/git-branching-naming-convention-best-practices/

• https://www.atlassian.com/git/tutorials/merging-vs-rebasing