Difference between revisions of "GitMajorWorkflow"
(Created page with " ==Introduction== Put the workflow for major development here. ==Workflow== > git checkout -b <meaningfulBranchName> where <meaningfulBranchName> is a name that encapsulat...") |
|||
| Line 2: | Line 2: | ||
==Introduction== | ==Introduction== | ||
| − | + | This is intended for development which will take more than a day, perhaps up to months, and may involve multiple contributors and validators, or should be documented in the git repository for some time. They may also mark breaking changes, need to be coordinated with product changes, other branches, or tags. Currently we plan to leave these branches visible in the repository until they are no longer of interest, at which time they may be archived so as to not clutter the repo forever. | |
| − | == | + | If you are new to git, please read the [[GitIntro|git intro]] and the [[GitMinorWorkflow|minor revision workflow]], which is very useful for concepts. |
| + | |||
| + | ==Overview== | ||
| + | |||
| + | The logical steps are as follows. | ||
| + | # checkout or create a work branch | ||
| + | # make revisions | ||
| + | # as needed, push this branch to the repo | ||
| + | # as needed, merge the head into your working branch | ||
| + | # when the changes are final, merge your branch into the head. | ||
| + | |||
| + | This workflow may span weeks, so steps 3 and 4 may need to be done several times. It is fine to save your work this way. It may be needed to tag the branch at various times, to pause for testing, for example, or to pass a given state to another worker. | ||
| + | |||
| + | |||
| + | ==Cheat Sheet== | ||
> git checkout -b <meaningfulBranchName> | > git checkout -b <meaningfulBranchName> | ||
Revision as of 22:06, 15 December 2017
Introduction
This is intended for development which will take more than a day, perhaps up to months, and may involve multiple contributors and validators, or should be documented in the git repository for some time. They may also mark breaking changes, need to be coordinated with product changes, other branches, or tags. Currently we plan to leave these branches visible in the repository until they are no longer of interest, at which time they may be archived so as to not clutter the repo forever.
If you are new to git, please read the git intro and the minor revision workflow, which is very useful for concepts.
Overview
The logical steps are as follows.
- checkout or create a work branch
- make revisions
- as needed, push this branch to the repo
- as needed, merge the head into your working branch
- when the changes are final, merge your branch into the head.
This workflow may span weeks, so steps 3 and 4 may need to be done several times. It is fine to save your work this way. It may be needed to tag the branch at various times, to pause for testing, for example, or to pass a given state to another worker.
Cheat Sheet
> git checkout -b <meaningfulBranchName>
where <meaningfulBranchName> is a name that encapsulates the set of software changes you'll be making, such as GeomForMARS2018a, etc.
Do your work. Edit/create/move files, etc. git add files to track them, commit them when ready.
Assuming this is a "long-term" development project, you'll want to occasionally bring in the most up-to-date master and make sure there are no conflicts. I'd like to see git experts weigh in on the best way to do this. Merge, rebase, other?
Also, I think we need to nail down our request to pull mechanism and get that into the cheat sheet.