0% found this document useful (0 votes)
53 views2 pages

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
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
53 views2 pages

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
We take content rights seriously. If you suspect this is your content, claim it here.
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

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy