Commit c0da4241 authored by Chris Bills's avatar Chris Bills

Update info about contributing / bringing in code

parent c16f9842
...@@ -9,7 +9,7 @@ ...@@ -9,7 +9,7 @@
Examples and more information about bash-functions, bash-git_prompt and git-aliases below the Getting Started guide. Examples and more information about bash-functions, bash-git_prompt and git-aliases below the Getting Started guide.
More information about branching, forking, rebasing, merging and all that good stuff can be found in this free online 'book': https://git-scm.com/book/en/v2 More information about branching, forking, rebasing, merging and all that good stuff can be found in this excellent (and free!) online book: https://git-scm.com/book/en/v2
### Getting Started with GitLab ### Getting Started with GitLab
...@@ -102,28 +102,37 @@ Ignore the 'rebase' example above if you're unfamiliar with rebase; it's only th ...@@ -102,28 +102,37 @@ Ignore the 'rebase' example above if you're unfamiliar with rebase; it's only th
### Contributing Changes ### Contributing Changes
Whether using the fork or branch workflows, contributing changes to a project (at least through GitLab) is pretty much the same. Whether you're using the fork or branch workflow, contributing your changes is pretty much the same process (at least when using GitLab).
When all is said and done, and you have work that is ready to be reviewed by others and potentially pushed to 'production', you will need to create a Merge Request on GitLab: Once you have made changes that you would like to contribute to a project, you will need to notify the maintainers (or "owners") of the project by making a Merge Request, within GitLab's Web UI.
* Browse to the project's page on GitLab (e.g. https://xgitlab.cels.anl.gov/systems/git-tips.git) OR your forked repository's page Making a Merge Request will send an email to the person you assign it to, and will show a diff of your branch versus the branch you are asking to merge your changes into. Follow the steps below to make a Merge Request in GitLab:
* Locate and click '+ New Merge Request' near the top right of the page (Subject to change as GitLab evolves)
* Select your source project and branch (e.g. systems/git-tips and 'foo', or username/git-tips and 'foo')
* Select your target project and branch (e.g. systems/project and 'prod')
* Click 'Compare Branches'
* Describe what your branch does and what testing you've done: don't rely on commit messages.
* Click 'Submit new merge request'
* Notify the main maintainer(s) of the project (they should receive an email, but...)
Your changes will be reviewed, and the maintainer(s) may have follow up questions for you or may ask you to make some changes, or squash some commits and generally clean things up. 1. Browse to the project's page on GitLab (e.g. https://xgitlab.cels.anl.gov/systems/git-tips.git) OR your forked repository's page
1. Locate and click '+ New Merge Request' near the top right of the page (Subject to change as GitLab evolves)
1. Select your source project and branch (e.g. systems/git-tips and 'foo', or username/git-tips and 'foo')
1. Select your target project and branch (e.g. systems/project and 'prod')
1. Click 'Compare Branches'
1. Describe what your branch does and what testing you've done: don't rely on commit messages.
1. Click 'Submit new merge request'
Now your changes are ready to be reviewed. The project maintainers may have followup questions for you or ask you to make changes.
Make any changes, as needed, and comment on the Merge Request when you are ready for another review. As long as you push your changes to the same branch of your initial Merge Request, you should not need to create another one.
### Bringing in Changes ### Bringing in Changes
This is a heated topic in some circles; some people prefer merging and merge commits, where others prefer a cleaner history and rebasing. The style should be determined by the maintainer(s), I personally prefer rebasing. If you are the maintainer of a project, you may need to respond to Merge Requests and occasionally bring changes in to the 'production' branch from contributor's forks or branches.
How you bring those changes in depends on your preferences; some people prefer merging and merge commits, where others prefer a cleaner / more linear history and using 'rebase'.
If you are responsible for maintaining a project, do yourself a favor and read about the various methods people use for bringing in changes.
I'd rather leave this hazy, for the time being, until people get more familiar with git; information about both methods is readily available. Merging is easy, especially within GitLab, because it can essentially all be done through the web interface using Merge Requests. Rebase (in my opinion) provides a clearer linear history of the project, but requires more understanding of git than this simple guide strives to impart.
Merging is easiest, especially with GitLab, because it can essentially all be done through the web interface. [Information on rebasing](http://git-scm.com/book/en/v2/Git-Branching-Rebasing)
[Rebase vs. Merge](http://git-scm.com/book/en/v2/Git-Branching-Rebasing#Rebase-vs.-Merge)
[Information on merging](http://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging)
### Migrating a Repository from Other Services ### Migrating a Repository from Other Services
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment