Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
33 views

ISD LAB00-Git&Github

This document provides guidelines for using Git and GitHub for a hands-on lab. It introduces Git and GitHub, shows how to use them with Eclipse, and explains common Git workflows like GitHub flow and release flow. It also provides a branching policy table that recommends naming conventions and merge targets for different types of branches like feature, bugfix, hotfix, refactor, and release branches.

Uploaded by

Tú Phạm
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
33 views

ISD LAB00-Git&Github

This document provides guidelines for using Git and GitHub for a hands-on lab. It introduces Git and GitHub, shows how to use them with Eclipse, and explains common Git workflows like GitHub flow and release flow. It also provides a branching policy table that recommends naming conventions and merge targets for different types of branches like feature, bugfix, hotfix, refactor, and release branches.

Uploaded by

Tú Phạm
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

1

Lab00: Git & Github Guidelines


Lecturer: NGUYEN Thi Thu Trang, trangntt@soict.hust.edu.vn

1. GIT & GITHUB


1.1. INTRODUCTION TO GITHUB
https://lab.github.com/githubtraining/introduction-to-github
1.2. GITHUB AND EGIT IN ECLIPSE
Git tutorial 1: creating github repo and sharing project in Eclipse
https://www.youtube.com/watch?v=cdsMIX9gB94
Git tutorial 2: Committing, pushing, pulling and resolving conflicts with git and
Eclipse
https://www.youtube.com/watch?v=M88sKbRDR8Y

2. GIT WORKFLOW
2.1. GitHub flow
https://guides.github.com/introduction/flow/
2.2. Release flow
https://devblogs.microsoft.com/devops/release-flow-how-we-do-branching-on-
the-vsts-team/
• We can create as many branches as we need.
• We name branches with meaningful names. See Table 1-Branching policy.
• We had better keep branches as close to master as possible (i.e., avoid
subbranch); otherwise, we could face merge hell.
• Generally, when we merge a branch with its origin, that branch has been
history. We usually do not touch it a second time.
• We use release branch as our assignment submission.

HANDS-ON LAB GUIDELINES


© 20XX – HUST – SOICT
ITSS SOFTWARE DEVELOPMENT – IT4945E
2

Name Naming Origin Merge to Purpose


of convention
Branch

feature + feature/feature- master master Add a new feature


or topic name or a topic
+ feature/feature-
area/feature-name
+ topic/description

bugfix bugfix/description master master Fix a bug

feature feature

hotfix hotfix/description master master & Hotfix a bug


releases [1]

refactor refactor/description master master Refactor

feature feature

release release/versionXX master none Assignment


submission

HANDS-ON LAB GUIDELINES


© 20XX – HUST – SOICT
ITSS SOFTWARE DEVELOPMENT – IT4945E

You might also like