Master Git Workflows: From Flow Models to Advanced Commands

Common Enterprise Git Branching Models

Three widely adopted branching models are described:

Git Flow – main, stable, develop, hotfix, feature branches.

GitHub Flow – create a branch, commit, open a pull‑request, review, test, merge.

GitLab Flow – production, environment, and release branches.

Daily Best‑Practice Tips

Prefer the command‑line interface for speed and clarity.

Write descriptive commit messages: a short subject (≤50 chars) followed by a blank line and a body (≤72 chars per line). Do not end the subject with a period.

Maintain a .gitignore file (or use a template) to exclude generated or irrelevant files.

Develop on feature branches or forks; never commit directly to master / main.

Use release branches (e.g., release/1.32) and tags (e.g., A‑feature, B‑bugfix) for version management.

Essential Commands

The basic workflow can be performed with three commands:

# stage changes (working tree → index)
$ git add <path>

# create a commit (index → local repository)
$ git commit -m "your message"

# push to a remote branch (local repository → remote)
$ git push origin master

Useful Configuration Options

Global settings (apply to all repositories):

# user identity
$ git config --global user.name "Your Name"
$ git config --global user.email "[email protected]"

# preferred editor
$ git config --global core.editor "nvim"

# pager for long output
$ git config --global core.pager "more"

# common aliases
$ git config --global alias.gs "git status"

# enable command‑line autocorrect (1 = prompt, 2 = auto‑fix)
$ git config --global help.autocorrect 1

Project‑specific configuration is stored in .git/config and is set without the --global flag.

Merge vs. Rebase

Merge preserves the complete history by creating a merge commit that records when branches were combined.

*   62a322d (HEAD→master) Merge branch 'hotfix3' into master
|\
| * 6fa8f4a (hotfix3) 3rd commit in hotfix3
* | 548d681 3rd commit in master
|/
* 6ba4a08 2nd commit
* 22afcc1 1st commit

Rebase rewrites commits onto a new base, producing a linear history. It should only be used on local, unshared commits.

* 697167e (HEAD→master, hotfix) 3rd commit
* 6ba4a08 2nd commit
* 22afcc1 1st commit

Principle: never rebase commits that have already been pushed to a shared repository.

Updating Repository History

Interactive rebase can reorder, squash, edit, or drop commits:

# edit the last five commits
$ git rebase -i HEAD~5
# example todo list
reword c2aeb6e 3rd commit
squash 25a3122 4th commit
pick 5d36f1d 5th commit
fixup bd5d32f 6th commit
drop 581e96d 7th commit

Amend the most recent commit without creating a new one:

# change the commit message
$ git commit --amend -m "new message"
# keep the existing message, only update the content
$ git commit --amend --no-edit

Use git revert to undo a public commit or git cherry-pick to apply a specific commit elsewhere.

Reflog for Recovery

Git records reference updates in the reflog, enabling recovery of lost commits:

# show recent reflog entries
$ git reflog

# recover a lost commit by cherry‑picking it
$ git cherry-pick 4bc8703

Batch Editing of History

When many commits need a global change (e.g., fixing author email), use git filter-branch on a temporary branch:

# create a testing branch
$ git checkout -b testing

# rewrite author information
$ git filter-branch --commit-filter '
    if [ "$GIT_AUTHOR_EMAIL" = "[email protected]" ]; then
        GIT_AUTHOR_NAME="escape"
        GIT_AUTHOR_EMAIL="[email protected]"
    fi
    git commit-tree "$@"
' HEAD

Hook Scripts

Executable scripts placed in .git/hooks are invoked at various points. Enable a hook by removing the .sample suffix and making the file executable.

Example: using the open‑source pre‑commit framework to run checks before a push.

# install the framework
$ pip install pre-commit

# .pre-commit-config.yaml example
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
  rev: v2.9.2
  hooks:
    - id: trailing-whitespace
    - id: flake8

# run checks automatically on push
$ git push origin master

Shallow Clone for Large Projects

Clone only the latest snapshot to avoid downloading the full history:

# shallow clone (depth = 1)
$ git clone http://example.com/repo.git --depth=1

Clone a specific tag without full history:

$ git init repo-15-0-1
$ git remote add origin http://example.com/repo.git
$ git -c protocol.version=2 fetch origin 15.0.1 --depth=1
$ git checkout FETCH_HEAD

Skip downloading large Git‑LFS files during clone:

$ GIT_LFS_SKIP_SMUDGE=1 git clone http://example.com/repo.git

Handling Work Interruptions

When you need to switch context without committing, stash the current changes:

# stash all changes, including untracked files
$ git stash -u

# list saved stashes
$ git stash list

# re‑apply a specific stash
$ git stash apply stash@{2}

# apply and delete in one step
$ git stash pop

Alternatively, push the work to a remote branch for backup before switching tasks.