A git workflow that is easy and scale for product development
There are numerous GIT workflow floating around like Centralized Workflow , Gitflow , Forking flow and Feature Branch Workflow
Over the last 10 years, I have followed this really simple workflow, similar to the forking flow.- it allow Parallel Development, features branches can be merged to any release branches or ideally Master
- Collaboration Feature branches also make it easier for two or more developers to collaborate on the same feature
We consider Master the stable version of the product, this branch should be deployed automatically using continuous delivery
Every ticket, bugs, fix, features
is done first in a new branch from master
- Using the ticket number first,
- with a short but understandable description written in lower case, e.g. PROJ-11-fix-login. This will let you create automatic releases notes because Jira and Confluence will recognize the ticket number in the branch name
These ticket, bugs, fix, features should NEVER be merged to master without a Pull Request (PR) and a code review.
After the review process it can be merged to master. (merge will be blocked if no reviewer has accepted the code changes)
Delivering code
Code deployed to production or customer instance can ONLY be deployed from a release branch name 1.0, 1.1, 1.2,….
Fixes in production or customer release
Fixes in production or customer release branch are done the usual way (ticket-name but branch created from release branch name) and create a new git tag 1.0.1 (first fix of release 1.0.1, then 1.0.2 ….)
These branches created from release branches can but must NOT be merged to master depending on the quality of the fix and urgency. To be discussed on a case by case basis
- e.g. hot ugly fixes, aka workaround, done in urgency for a customer won’t be merged to master and may be rewritten to finally be merged to master later.
- But the normal case it that these fixes will be merged to master.
Conclusions
This workflow has allowed me in the past to handle multiple version (1.1, 1.2.5, 1.5) of a corporate product run by multiple client at the same time. Even if supporting multiple version is not a desirable setup in the long run…
Merging Two Git Repositories Into One Repository Without Losing File History
There seems to be a lot of way to merge two #git repositories into one repository without losing file history. Here is another straightforward method.
This method do not use #submodules or #subtree merges. it uses regular merge operations.
- Create a new empty repository New.
- Make an initial commit because we need one before we do a merge.
- Add a remote to old repository A.
- Merge A/master to New/master.
- Make a subdirectory folderA.
- Move all files into subdirectory folderA.
- Commit all the file moves.
- Repeat 3-6 for another repository.
mkdir result cd result git init touch README.MD git add . git commit -m "added readme.md"
Step 3 to 6
git remote add -f A https://github.com/A.git git fetch --all git merge --allow-unrelated-histories A/master mkdir folderA git mv -k * folderA git commit -m “moved A files into subdir folderA”
Stitching several git repositories into a git fast-import stream
git-stitch-repo
Stitch several git repositories (merging git repository) into a git fast-import stream from Git-FastExport
Installation
$ perl -MCPAN -e shell cpan[6]> i /fastexport/ Distribution BOOK/Git-FastExport-0.107.tar.gz Module < Git::FastExport (BOOK/Git-FastExport-0.107.tar.gz) Module < Git::FastExport::Block (BOOK/Git-FastExport-0.107.tar.gz) Module < Git::FastExport::Stitch (BOOK/Git-FastExport-0.107.tar.gz) 4 items found cpan[6]> install BOOK/Git-FastExport-0.107.tar.gz cpan[6]> CTRL-D
Usage
git-stitch-repo will process the output of git fast-export –all –date-order on the git repositories given on the command-line, and create a stream suitable for git fast-import that will create a new repository containing all the commits in a new commit tree that respects the history of all the source repositories. Typical usage is like this:
git clone https://github.com/xxxx/A.git git clone https://github.com/xxxxx/B.git $ ls A B mkdir result cd result git init git-stitch-repo ../A:folderA ../B:folderB | git fast-import # pull both repository in a new branch for examples git checkout -b newBranch git pull . master-A git pull . master-B # when finished delete unused branches git branch -d master-A git branch -d master-B
