Git Development Process

Typical development workflow ¶

First time create local workspace ¶

Command Line ¶

1. Run git clone mainline-url.

   git clone <origin-url>
   

2. Run git config to set author name and email for this repo.

   git config user.name "<your-cec>"
   git config user.email <your-email>
   

3. Create a fork (bottom left corner for BitBucket, up right corner for GitHub).

4. Set a remote to point at your fork.

   git remote add <your-cec> <your-fork-url>
   

5. Check if set successfully.

   git remote -v # if you see two remote upstreams (one is origin, the other is your cec), you are success
   

Recommend to set base repository as origin, your own fork as cec.

Source Tree ¶

1. Clone remote repository

   • Clone from URL
   • Clone a repository
   • Double click newly cloned repository

2. Set author name and email for this repo.

3. Create a fork (bottom left corner for BitBucket, up right corner for GitHub).

4. Add a remote to point at your fork.

   • Go to Settings -> Remotes
   • Add your fork as remote

5. Check if set successfully.

Short-lived individal feature development ¶

This is the most common case.

Command Line ¶

1. Create feature branch on your own fork based on origin master.

   git checkout -b <feature-branch> origin/master # create a new branch based on origin master
   git pull # keep code updated with remote
   git push -u <your-fork> <feature-branch> # push the branch to your own fork
   

2. Add your feature code and unit tests. Make sure everything runs fine before you continue your merge process.

3. Commit your changes.

   git add . # or add any needed files
   git commit -m "<commit messages>"
   

4. Update code from origin master (fix conflict if needed).

   git pull origin master --rebase # update your code on rebase mode
   

5. Push your code to remote tracking branch.

   git push <your-fork> <feature-branch> # push local commits to your remote fork
   

6. Go to GitHub or BitBucket to rise a Pull Request to master.

7. During review processing, Iterate step 3 to step 5 until your PR enables the merge button, then merge.

8. (Recommend to delete the feautre branch to keep workspace clean)

9. (Integration test based on master)

Source Tree ¶

1. Create feature branch on your own fork based on origin master.
   • Pull from origin/master to update latest code
   • Create new branch based on local master (branch that tracking origin/master)
2. Add your feature code and unit tests. Make sure everything runs fine before you continue your merge process.
3. Commit your changes.
4. Update code from origin master (fix conflict if needed).
5. Push your branch and code to your remote own fork.
6. Go to GitHub or BitBucket to rise a Pull Request to master.
7. During review processing, Iterate step 3 to step 5 until your PR enables the merge button, then merge.
8. (Recommend to delete the feautre branch to keep workspace clean)
9. (Integration test based on master)

Short-lived shared feature branch development ¶

This case applies to collaborative development, and the feature can be finished within current sprint (can be merged to master shortly).

This case is just the same as the branch based development model.

Command Line ¶

1. Create feature branch on origin based on master.

   git checkout -b <feature-branch> origin/master # create a new branch based on origin master
   git pull # keep code updated with remote
   git push -u origin <feature-branch> # push the branch to origin
   

2. Add your feature code and unit tests. Make sure everything runs fine before you continue your merge process.

3. Commit your changes.

   git add . # or add any needed files
   git commit -m "<commit messages>"
   

4. Update code from origin master (fix conflict if needed).

   git pull # update code from remote tracking branch incase there is any updates made by your peer.
   git pull origin master --rebase # update your code on rebase mode
   

5. Push your code to remote tracking branch.

   git push origin <feature-branch> # push local commits to remote
   

6. Go to GitHub or BitBucket to rise a Pull Request to master.

7. During review processing, Iterate step 3 to step 5 until your PR enables the merge button, then merge.

8. (Recommend to delete the feautre branch to keep workspace clean)

9. (Integration test based on master)

Source Tree ¶

1. Create feature branch on your own fork based on origin master.

   • Pull from origin/master to update latest code
   • Create new branch based on local master (branch that tracking origin/master)

2. Add your feature code and unit tests. Make sure everything runs fine before you continue your merge process.

3. Commit your changes.

4. Update code from feature branch (if there is parallel update) and origin master (fix conflict if needed).

   

   

5. Push your code (and branch) to remote origin.

   

6. Go to GitHub or BitBucket to rise a Pull Request to master.

7. During review processing, Iterate step 3 to step 5 until your PR enables the merge button, then merge.

8. (Recommend to delete the feautre branch to keep workspace clean)

9. (Integration test based on master)

Long-lived shared feature branch development ¶

This is a extended case for above collaborative development, the feature cannot be finished within current sprint, in other words, feature branch can not be merged to master shortly, which may lead to problem for integration test.

• There is a toggle align with current feature Just do as Short-lived shared feature branch development case, and keep toggle closed on Production environment before feature fully released.
• Do not have a feature toggle
  • When the feature is partly done, and there is a milestone needs to be tested, do step 1 to step 5 as Short-lived shared feature branch development case, then create a temp branch based on origin master, and merge all feature code to this branch, at last, release a package from the temp branch for integration test.
  • When the feature is fully done, do as Short-lived shared feature branch development case.

Normally this pattern should be strictly forbidden, especially after we enabled CICD pipeline some day.

Release flow ¶

Developing a feature ¶

Dealing with an EP ¶

Time Frame ¶

Key Event ¶

Reference ¶

Git Best Practice

MCT CI/CD Workflow