GNU/Linux Desktop Survival Guide
by Graham Williams |
|||||
Git Developer Workflow |
20210113 Also see Section 88.24 and following for other workflow suggestions.
1. Clone a Repository
A generic git workflow for a team, with developers working on specific tasks/tickets/issues, begins with a clone of the repository. The URI identifies the repository (e.g., git@github.com:...) and can be obtained from the Code button of the github repository through the browser. The command to clone is:
$ git clone git@github.com:<owner>/<repo>.git |
2. Create a Branch
For a specific task create a branch, generally from the main branch, to encapsulate the work. For a task to add a feature to validate user input, the branch might be called validator:
$ git checkout main # Ensure main branch is the default. $ git pull --rebase # Download to local any changes to main. $ git branch validator # Create a new branch named validator. $ git checkout validator # Make this branch the default. $ git push --set-upstream origin validator # Notify the upstream repo of this branch. |
A shortcut to create and check out a branch is to add -b
to
the checkout command.
$ git checkout -b validator # Create new branch and check it out. |
3. Coding
Undertake the activity on that branch locally and commit (to share your work) regularly to the branch. Test the branch in the development environment for your deployment.
4. Prepare for Pull Request
When the body of work has been completed and tested and confirmed as ready for deployment into production, pull from the remote (origin) to your local branch to resolve any conflicts. Then commit and push your work back to the remote branch:
$ git pull --rebase # Retrieve latest updates from main. $ git commit . -m "Helpful yet brief commit message." # Commit changes. $ git push # Puch changes to the remote repo. |
5. Create Pull Request
Navigate through a browser to this branch on github and click on "Pull request" (command line alternative is to use gh). Be sure to assign a reviewer and link the pull request (PR) to the issue you're working on if there was one.
The reviewer may make comment on the request, and may require changes before the pull request can be merged.
6. Merge Pull Request and Delete Branch
Once reviews are complete and the pull request is approved, the repository owner can then merge the request into main.
Once the PR has been merged delete the branch to keep the repository uncluttered.