Skip to content

Git Workflow

Jump to bottom
Bhaskar Singh edited this page May 28, 2020 · 5 revisions

A Rebase-Based Git Branching Model(Best suited for a team of 2 to 5 people)

Rules

  • master must always be deployable(No pushing directly to the master branch).
  • All changes must be made in a pull-request through a feature branch
  • rebase continually from develop branch (before beginning work on a feature branch) to avoid/resolve conflicts;
  • merge feature branches into integration(develop) branch with --no-ff flag.
  • before merging into develop branch, all feature commits should be squashed into single commit squasing commits
  • Merged into develop != In production

The master branch stores the official release history, and the develop branch serves as an integration branch for features. All commits in the master branch are tagged with a version number and the master branch shows the latest deployable production changes.

Example

Assuming we have a repo set up with a master as (production branch) and develop branch as an integration branch. A complete example demonstrating an Integration Branch Flow is as follows:

# create a new branch for every logical change
git checkout -b feature-x
# work happens on the feature-x branch
#rebase feature-x branch with develop branch
git rebase develop
#resolve conflict if any
#then checkout develop branch
git checkout develop
git merge --no-ff feature-x # or pull request to develop branch via GitHub 
git branch -d feature-x branch

IMPORTANT NOTE: Note the git pull --rebase before you push. This is so you don't get merge conflicts. Remember you should never rebase develop itself and force push it, like you would a feature branch, but that's not what you are doing here. Here, you are just ensuring that your local changes are rebased ONTO develop BEFORE you push them, and avoiding a possible separate merge-conflict-resolving commit

# keep abreast of other changes to develop branch.
# rebasing keeps our code working, merging easy, and history clean.
# Do this often - at the beginning of every day, and after every
# push to the feature branch
git fetch origin
git rebase origin/develop
# IMPORTANT NOTE: If you have conflicts, always use '--continue', never '--skip'.
#                 See "DOs" and "DON'Ts" below.  If you are confused, ask for help


# after you are done merging your feature branch back to develop and pushing, delete the local
# branch with the '-d' option (not forced, like -D).  if you have successfully merged
# all the feature branch's commits to `develop` branch, this no-force delete command should complete
# with no warnings or errors, because git knows all the commits on the branch have 
# been successfully merged to develop.
git branch -d my-new-feature

# Then, delete the remote branch off of github:
git push --delete origin my-new-feature

# then everyone else can do a fetch with --prune to clean up the branch
# off their local machines
git fetch --prune

useful config

# autosetup rebase so that pulls rebase by default(for develop branch)
git config branch.<branchname>.rebase true

DOs and DON'Ts

DOs

  • DO keep develop in working order.
  • DO rebase your feature branches.
    • DO pull in (rebase on top of) changes
  • DO tag releases
  • DO push feature branches for discussion
  • DO learn to rebase
    • When rebasing in changes and resolving conflicts, always use '--continue' - never skip conflicts

DON'Ts

  • DON'T EVER force push master! This includes push +master
  • DON'T rebase the remote master (Note that doing pull --rebase prior to a push doesn't count at as "remote").
  • DON'T merge in broken code.
  • DON'T merge with conflicts. handle conflicts upon rebasing.
    • When rebasing, you should NEVER commit a merge conflict! If you end up with a merge conflict, you did something wrong, and should abort and start over.

FAQ

Won't git merge --no-ff generate merge bubbles?

Yes. Merge bubbles aren't inherently bad. They allow you to revert entire features at a time. They get confusing and annoying to deal with if they cross (commits interleave), so don't do that.

GitHub notes

Don't fork. Push feature branches to the main repo.

Sometimes I see people forking repositories in order to issue pull-requests. Yes, you may have to do this when contributing to open-source projects you don't regularly contribute to. But, if you are a contributor, or working in the same org, get push rights on the repo and push all your feature branches to it. Issue pull requests from one branch to another within the same repo.

Should I merge Pull Requests on the site or command line?

Up to you. Github does git merge --no-ff so that the commit message indicates the pull request number. This is useful information to have, don't just throw away history for the sake of it. You never know what will be useful to look at in the future.

Reference link:

Clone this wiki locally