Git - Best Practices - Revision history

Lsokolowski1 at 10:25, 15 September 2025

2025-09-15T10:25:56Z

← Older revision		Revision as of 10:25, 15 September 2025
Line 64:		Line 64:
	*** to enforce rules for access control (gitolite, gitlab)		*** to enforce rules for access control (gitolite, gitlab)
	*** for code review (Gerrit or the pull requests of GitHub, Bitbucket, or GitLab)		*** for code review (Gerrit or the pull requests of GitHub, Bitbucket, or GitLab)

			== Some cheats ==
			<pre>
			git checkout file_name VS git restore file_name
			git reset file2 VS git restore --staged
			git reset --hard HEAD VS git reset --hard cbd123 (not HEAD)
			git branch nb 84fe ; git checkout nb VS git checkout -b nb 84fe VS git switch -c nb 84fe
			git branch --no-merged --merged ; git branch --verbose --all
			</pre>

	== Some hands-on ==		== Some hands-on ==

Lsokolowski1: /* Some hands-on */

2025-09-15T10:22:57Z

Some hands-on

← Older revision		Revision as of 10:22, 15 September 2025
Line 66:		Line 66:

	== Some hands-on ==		== Some hands-on ==
	* fetch-reset-stash-pull-stash way		* '''fetch-reset-stash-pull-stash''' way

	=== fetch-reset-stash-pull-stash ===		=== fetch-reset-stash-pull-stash ===

Lsokolowski1 at 10:22, 15 September 2025

2025-09-15T10:22:40Z

← Older revision		Revision as of 10:22, 15 September 2025
Line 6:		Line 6:


	== Git Best Practices ⌘==		== Git Best Practices ==
	* Dividing work into repositories		* Dividing work into repositories
	* Selecting the collaboration workflow		* Selecting the collaboration workflow
Line 14:		Line 14:
	* Other		* Other

	=== Working on a project ⌘===		=== Working on a project ===
	* Working on a topic branch		* Working on a topic branch
	** long-running public branches		** long-running public branches
Line 25:		Line 25:
	** and you begin to see that you have two independent changes squished together		** and you begin to see that you have two independent changes squished together

	=== Working on a project (con't) ⌘===		=== Working on a project (con't) ===
	* Writing a good commit message		* Writing a good commit message
	** Should not require other devs to read actual changes to find out what the commit intends to do		** Should not require other devs to read actual changes to find out what the commit intends to do
Line 36:		Line 36:
	*** but DO NOT REWRITE THE PUBLISHED HISTORY		*** but DO NOT REWRITE THE PUBLISHED HISTORY

	=== Integrating changes ⌘===		=== Integrating changes ===
	* Submitting and describing changes		* Submitting and describing changes
	* Change review		* Change review
Line 45:		Line 45:
	* Responding to reviews and comments		* Responding to reviews and comments

	=== Other ⌘===		=== Other ===
	* Recovery is almost always possible		* Recovery is almost always possible
	** commit or stash before 'git reset --hard'		** commit or stash before 'git reset --hard'
Line 56:		Line 56:
	** Choose proper convention		** Choose proper convention

	=== Other (con't) ⌘===		=== Other (con't) ===
	* Automate what is possible		* Automate what is possible
	** facilitate your dev standards with client-side hooks		** facilitate your dev standards with client-side hooks
Line 65:		Line 65:
	*** for code review (Gerrit or the pull requests of GitHub, Bitbucket, or GitLab)		*** for code review (Gerrit or the pull requests of GitHub, Bitbucket, or GitLab)

	== Some hands-on ===		== Some hands-on ==
	* fetch-reset-stash-pull-stash way		* fetch-reset-stash-pull-stash way

Lsokolowski1 at 10:21, 15 September 2025

2025-09-15T10:21:47Z

@@ Line 1: / Line 1: @@
 [[Category:Git]]
-<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="true" font="Trebuchet MS" >
 ;title: Git Best Practices
 ;author: Lukasz Sokolowski
-</slideshow>
 == Git Best Practices ⌘==
@@ Line 64: / Line 64: @@
 *** to enforce rules for access control (gitolite, gitlab)
 *** for code review (Gerrit or the pull requests of GitHub, Bitbucket, or GitLab)

Łukasz Sokołowski at 00:39, 22 July 2016

2016-07-22T00:39:34Z

New page

[[Category:Git]]

<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="true" font="Trebuchet MS" >
;title: Git Best Practices
;author: Lukasz Sokolowski
</slideshow>

== Git Best Practices ⌘==
* Dividing work into repositories
* Selecting the collaboration workflow
* Choosing which files to keep under version control
* Working on a project
* Integrating changes
* Other

=== Working on a project ⌘===
* Working on a topic branch
** long-running public branches
** short-lived private branches
* Deciding what to base your work on
** never merge a less stable branch into a more stable branch
** bugfix, new feature, corrections and enhancements
* Splitting changes into logically separate steps
** If your description gets too long
** and you begin to see that you have two independent changes squished together

=== Working on a project (con't) ⌘===
* Writing a good commit message
** Should not require other devs to read actual changes to find out what the commit intends to do
** Why
** How
** Alternate solutions (considered but discarded, etc)
** Issue descr (number, pattern, etc)
* Preparing changes for submission
** Consider rebasing to do final-clean up of the history
*** but DO NOT REWRITE THE PUBLISHED HISTORY

=== Integrating changes ⌘===
* Submitting and describing changes
* Change review
** Wrong problem
** Does not work
** Fails best practices
** Does not match reviewer preferences
* Responding to reviews and comments

=== Other ⌘===
* Recovery is almost always possible
** commit or stash before 'git reset --hard'
** use reflog
** messed wc? - do -i add, reset, checkout
** use a lot 'git status'
* Don't change the published history
** use 'git revert' if necessary
* Numbering and tagging releases
** Choose proper convention

=== Other (con't) ⌘===
* Automate what is possible
** facilitate your dev standards with client-side hooks
*** or enforced them with server-side hooks
*** hooks can protect against rewriting history
** consider third-party solutions
*** to enforce rules for access control (gitolite, gitlab)
*** for code review (Gerrit or the pull requests of GitHub, Bitbucket, or GitLab)