DevUA

New


Categories


Tags


Meta


DevUA


convention1

We just migrated our source code to Git (GitLab) so that we decided to develop some git convention. I share our internal kitchen ’cause it could be useful for others as well. The main idea keeping master as only source for releases and all development should be done on branch called dev. Also we keep in reserve branch stage in case we will have to provide separate branch for qa purpose. For now we do not have dedicated QA on the given project so we directly merge from dev to master but if you have QA on project use following merge scheme dev -> stage -> master. Also on GitLab we have configured CI. For each push to remote repository CI builds project and show warning on MergeRequest in case project build/test fails.

Precondition

  1. We will use branch master only for releases!!!
  2. All changes should be merged to branch called dev and only then moved to master
  3. All changes from dev should be moved to master with GitLab Merge Requests. Do not run any actions manually through console!
  4. All development should be done on private branch created for each new task
  5. All changes from private branches should be moved to dev with GitLab Merge Requests
  6. Private branch should be deleted after approval of Merge Request

How to create dev branch

  1. Switch to master
    git checkout master
  2. Pull latest changes from origin master with discarding any local changes
    git pull --rebase origin master
  3. Create new branch dev on local env
    git checkout -b dev
  4. Push  local branch dev with command
    git push -u origin dev

How to create new private branch for development and then create Merge Request

  1. Sync local environment with git repository structure. Execute command once to let your local structure know about dev branch
    git fetch
  2. Switch to branch dev
    git checkout dev
  3. Get latest changes from dev
    git pull --rebase origin dev
  4. Create and switch to private branch
    git checkout -b  <my_private_branch_name>
  5. Development itself
  6. Commit your changes to local repository
    git commit -am "commit description"
  7. Push changes to remote repository
    git push -u origin <my_private_branch_name>

    Pay attention on key -u.  You can find good explanation on StackOverflow

  8. Create Merge Request with GitLab user interface. I recommend to select option “Remove source branch” and if you have enterprise version of GitLab also select option “Squash commits”
  9. Review Merge Request!
  10. Resolve conflicts if required
  11. Switch to branch dev again
    git checkout dev
  12. If you would like to remove local branches which are already removed on remote execute
    git fetch --prune

How to resolve Merge Request conflicts

  1. Switch to local version of dev
    git checkout dev
  2. Pull latest changes from origin dev with discarding any local changes
    git pull --rebase origin dev
  3. Switch back to private branch
    git checkout <my_private_branch_name>
  4. Rebase private branch on top of dev latest changes (reapply your work on top of the incoming changes)
    git rebase dev
  5. Resolve conflicts manually in conflicted files with IDE
  6. Commit changes
    git commit -m "commit description"
  7. Push changes with force key
    git push -f origin <my_private_branch_name>
  8. On this step Merge Request could be approved by reviewer

P.S.

In case you need to remove local branches which already deleted on remote repo, call

git remote prune origin

List all local branches with command

git branch

If you found mistake or just have some idea for improvement – let me know by mail andriy@andrunevchyn.com

Git mastering

We just migrated our source code to Git (GitLab) so that we decided to develop some git convention. I share our internal kitchen ’cause it could be useful for others as well. The main idea keeping master as only source for releases and all development should be done on branch called dev. Also we keep […]

Andriy AndrunevchynAndriy Andrunevchyn