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.
// 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
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.
Merge between main branches should always be --no-ff merge
Merge feature branches on main branch should always be --no-ff merge