| Re: [4diac-dev] Suggestion of using git-flow like workflow for development |
|
Hi, I prepared a first draft of what might be a git cheat sheet with some introduction to the workflow. The idea is to have
all the important and most used information about git in one simple file, instead of going through pages and pages of tutorials. I leave it in txt so you can edit it (specially the push and fetch, which I’m not so sure about). I know that it’s not a good idea
to make file revision through email, but at least to have some opinions and the group moving. If the document goes well, it can be added to the documentation of the git project.
Regards, Jose Cabral --
fortiss
· An-Institut Technische Universität München Guerickestraße 25
80805 München Germany Tel.: +49 (89) 3603522 0 Fax: +49 (89) 3603522 50
E-Mail:
cabral@xxxxxxxxxxx Amtsgericht München: HRB: 176633 USt-IdNr.: DE263907002, Steuer-Nr.: 143/237/25900 Rechtsform: gemeinnützige GmbH Sitz der Gesellschaft: München Geschäftsführer: Prof. Dr. Helmut Krcmar, Thomas Vallon Vorsitzender des Aufsichtsrats: Dr. Ronald Mertz Von: 4diac-dev-bounces@xxxxxxxxxxx [mailto:4diac-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Gerhard Ebenhofer Hi, from my point of view it seems to be a good "workflow". As I'm currently not that familiar with the git commands (especially with advanced options like "--no-ff" as mentioned in the articles
you linked) - it might be useful to have something like a "cheat-sheet" with the main git commands (and the corresponding UI functionalities in EGit) to be used in the 4DIAC-git-flow workflow. Do you think it is possible and usefull that we make a "4DIAC - git-flow workflow" cheat sheet? Regards, Gerhard On Fri, Mar 4, 2016 at 2:41 PM, Alois Z. <alois.zoitl@xxxxxx> wrote:
|
# Git-workflow cheat sheet This document tries to put together the basic information needed to keep the workflow used with GIT in the 4DIAC project (and many others actually). ## Terms HEAD: Commit where currently the working directoy is. Staged area: set of files that were changed and that are going to be included in the next commit. Working area: set of files changed but not selected to go to the next commit ## Branches The branches used in the workflow are: 1. master: main branch where the HEAD always reflects a production-ready state (only release versions) 2. develop: used to reflect the latest development changes for the next release. 3. hotfix: used for quick fixes in the master branch. MUST branch off master, and MUST merge into master OR develop. Name convention: hotfix-* 4. release: support preparation for new release. When all feature are done, this branch focuses and last details and bugs. MUST branch off develop, and MUST merge back into develop OR master. Name convention: release-* 5. features branches: used to develop new features for the future releases. MUST merge off and into develop. Name convention: any except master, develop, release-*, or hotfix-* Example: Version 1.0 is ready, and a new version (no number yet) is on development. The HEAD of master points to version 1.0. From the develop branch, branch off all the features that will be added to the the new vesrion. When a feature is done, it is merged into develop and the feature branch deleted. When all the features are done, a release branch is branch off from develop, and bugs are fixed to prepare the new version. When the release branch is branched off, is when the number of the new version is decided (let's say 2.0). When all the bugs are fixed, the release branch is merged into master which is tagged, and also to the develop branch, so it will contains the fixes in the future. If a critical error is found after the new version, the bug is taken care of in a new hotfix branch. ## GIT commands 1. Creating a newFeature branch: (remember to clean your workspace before switching branches) $ git checkout originBranch /* switch to originBranch, from where you will branch off */ $ git branch newFeature /*creates the newFeature branch, but don't switch to it yet */ $ git checkout newFeature /*switch to newFeature branch */ $ git push origin newFeature /* OPTIONAL: push the new branch to the origin remote */ SHORTCUT 1: $ git checkout -b newFeature originBranch /* do all the above in one command */ SHORTCUT 2: (supposing you are currently in originBranch) $ git checkout -b newFeature /* creates and switch to newFeature from current branch */ 2. Add a newFile file to the git project: $ git add newFile 3. Add the changes to newFile for the next commit (from working area to staged area): $ git add newFile /* Yes, same as adding a file to the project */ 4. See what has been changed, what is ready to be commited and what not (see working and staged areas): $ git status 5. See the difference between last commit and the staged area: $ git diff --staged OR $ git diff --cached 6. See the difference between the staged and working areas: $ git diff 7. Commit changes: $ git commit /* will open a text editor to write the message for the commmit */ 8. Ammend commit $ git commit --amend /*will replace the last commit with this new one. Normally used when some minor changes were forgotten, or to change the message of the commit. */ 9. Merge the newFeature branch to develop when it's done: $ git checkout develop /* switch to develop branch */ $ git merge --no-ff newFeature /* merge branch. The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. Makes the history cleaner*/ $ git branch -d newFeature /* delete the newFeature branch */ $ git push origin develop /* push the develop to origin */ $ git push origin --delete newFetaure /* deletes the branch in the origin */ 10. See branches $ git branch /* the one with the asterisk (*) is the current branch */ 11. Get new information from origin $ git fetch origin /* get new data from origin */ /* Supoose there's a new branch in origin called newBranch that you see when you executed the last command, then to merge this new branch to your local project, you do: */ $ git checkout -b newBranch origin/newbranch or its SHORTCUT: $ git checkout --track origin/newBranch /* If you have a tracking branch set up git pull will look up what server and branch your current branch is tracking, fetch from that server and then try to merge in that remote branch.*/ $ git pull 12. Delete oldFile file from hard drive $ git rm oldFile /* will remove file from hard drive, and the oldFile will be marked as delete in the staged are ready to be commited. If oldFile is simple erased, it will appear in the non-staged area as deleted, and 13. Untrack oldFile (remove from git, but no from hard drive): $ git rm --cached oldFile /* deletes from git but no from hard-drive */ 14. Move or rename file $ git mv oldName newName /* change the file's name */ 15. See commit history $ git log /* shows the commit history */