git
best practice
-
Commit Related Changes
Small commits make it easier for other team members to understand the changes and roll them back if something went wrong. For example: fixing two different bugs should produce two separate commits. Formatting commits should be separated from issue commits. -
Commit Often (it doesn't mean push often)
Committing often keeps your commits small and, again, helps you commit only related changes. Having few large commits and sharing them rarely, in contrast, makes it hard both to solve conflicts and to comprehend what happened. - Don’t Commit Half-Done Work
Split the feature’s implementation into logical chunks and remember to commit early and often - Test Before You Commit
- Write Good Commit Messages
#issue short summary, descriptive body of changes.
Use the imperative, present tense ("change", not "changed" or "changes") to be consistent with generated messages from commands like git merge. - Use Branches (!!)
Short-Lived / Topic Branches
- They are about a single topic and are used to isolate code belonging to this topic from any other code.
- They typically have a rather short lifespan, usually only until you've finished working on the topic (i.e. when the bug is fixed, the feature is complete...). Then, the branch will be integrated into the broader context of your project and can be deleted.
Long-Running Branches
- They represent states in your project lifecycle - like a "production", "testing", or "development" state - and remain in your project for a longer time.
- You shouldn't work on them directly. Instead, you integrate other branches (possibly feature branches or other long-running branches) into them, but rarely add commits directly to them.
- Often, long-running branches have a hierarchy between them: e.g. "master" is used as the highest-order branch. It should only contain production code. Subordinate to it exists a "development" branch. It's used to test developed features and is then integrated into "master"...
// what do we usually do
$ git branch
* master
// edit and files commit
$ git add .
$ git commit
// push
$ git push
To https://github.com/batopa/Hello-World.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'https://github.com/batopa/Hello-World.git'
// git pull
$ git pull
$ git log
Merge branch 'master' of https://github.com/batopa/Hello-World
Common workflow error
// where am I?
$ git branch
* master
// change branch if needed
$ git checkout develop
// create new branch
$ git checkout -b issue/xxx-description
// do some work
....
// add and commit
$ git add files
$ git commit
// do other stuff, commits, drink coffee, play tennix, etc...
...
// prepare to merge
$ git checkout develop
$ git pull
// merge
$ git merge issue/xxx-description
// push, finally
$ git push
Issue Workflow
fast-forward merge
3-way merge
--no-ff merge (No Fast-Forward)
Merge the specified branch into the current branch, but always generate a merge commit (even if it was a fast-forward merge).
This is useful for documenting all merges that occur in your repository.
Workflow depends to project
- BEdita (master is develop line, 3-corylus is stable)
- Frontends (usually only one main branch: master)
- ieBook (4 main branches master, release, test, develop)
Merge between main branches should always be --no-ff merge
Merge feature branches on main branch should always be --no-ff merge
git, best practice
By Alberto Pagliarini
git, best practice
- 1,033