Git

Branching strategies:

Implement branch strategies

Another important aspect of Git is having a good branch strategy. A branch strategy gives structure to how features are developed, how hotfixes and patches are created, and to the whole development lifecycle. Three popular branch strategies that are Git-based are: the Feature Branch Workflow, the Gitflow Workflow, and the Forking Branch Workflow.

Feature Branch Workflow

The core idea behind the Feature Branch Workflow is that all feature development takes place in a dedicated branch instead of the master branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means the master branch will never contain broken code, which is a huge advantage for continuous integration environments.

The Feature Branch Workflow assumes a central repository, and master represents the official project history. Instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature. Feature branches should have descriptive names, like new-banner-images or bug-91. The idea is to give a clear, highly-focused purpose to each branch. Git makes no technical distinction between the master branch and feature branches, so developers can edit, stage, and commit changes to a feature branch.

Gitflow Workflow

The Gitflow Workflow defines a strict branching model designed around the project's release. It provides a robust framework for managing larger projects.

Gitflow is ideally suited for projects that have a scheduled release cycle. This workflow doesn't add any new concepts or commands beyond what's required for the Feature Branch Workflow. Instead, it assigns very specific roles to different branches and defines how and when they should interact. In addition to feature branches, it uses individual branches for preparing, maintaining, and recording releases. Of course, you also get all the benefits of the Feature Branch Workflow: pull requests, isolated experiments, and more efficient collaboration.

Gitflow uses a central server model called origin. Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. Feature branches may branch off from develop branch and must merge back into develop. Release branches may branch off from the develop branch and must merge back into the develop and master branches. For hotfixes, you use the hotfix branch, which is cut from the master branch, and then merged back into the master and develop branches.

Forking Branch Workflow

The Forking Workflow is fundamentally different than other popular Git workflows. Instead of using a single server-side repository to act as the "central" codebase, it gives every developer their own server-side repository. This means that each contributor has not one, but two Git repositories: a private local one and a public server-side one. The Forking Workflow is most often seen in public open source projects.

The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository. This allows the maintainer to accept commits from any developer without giving them write access to the official codebase.

The Forking Workflow typically follows a branching model based on the Gitflow Workflow. This means that complete feature branches will be merged into the original project maintainer's repository. The result is a distributed workflow that provides a flexible way for large, organic teams (including untrusted third-parties) to collaborate securely.

As in the other Git workflows, the Forking Workflow begins with an official public repository stored on a server. But when a new developer wants to start working on the project, they do not directly clone the official repository.

Instead, they fork the official repository to create a copy of it on the server. This new copy serves as their personal public repository. No other developers are allowed to push to it, but they can pull changes from it. After they have created their server-side copy, the developer performs a git clone to get a copy of it onto their local machine. This serves as their private development environment, just like in the other workflows.

When they're ready to publish a local commit, they push the commit to their own public repository—not the official one. Then, they file a pull request with the main repository, which lets the project maintainer know that an update is ready to be integrated.

Overall: https://jwiegley.github.io/git-from-the-bottom-up/

Git concepts: https://dev.to/unseenwizzard/learn-git-concepts-not-commands-4gjc Commit messages: https://chris.beams.io/posts/git-commit/ Commit: https://blog.thoughtram.io/git/2014/11/18/the-anatomy-of-a-git-commit.html

Use git pull rebase

Straipsniai: Apie komitų rašyma: https://dev.to/maniflames/how-conventional-commits-improved-my-git-skills-1jfk?utm_source=digest_mailer&utm_medium=email&utm_campaign=digest_email

Git branching: https://reganmusic.wordpress.com/2016/07/19/branching-in-tortoise-git/ Git workflow: https://dev.to/adityasridhar/how-to-use-git-efficiently-2pfa?utm_source=Newsletter+Subscribers&utm_campaign=1976d8dbe4-EMAIL_CAMPAIGN_2018_11_05_11_27&utm_medium=email&utm_term=0_d8f11d5d1e-1976d8dbe4-154198941

TO GET CHANGES FROM MASTER INTO A BRANCH:

1. Be on the created branch and then: Commit, Fetch and Rebase, and push your local changes;

2. Switch to parent branch and then: Fetch and Rebase server changes;

3. Switch to created branch;

4. Rebase...;

5. Branch: created branch;

6. Upstream: master;

To create new branch with comitted local changes:

1. Commit all changes locally;

2. Create new branch;

3. From master -> choose commit to fall back to -> "Reset master to this.." -> "Medium";

4. Dont forget to undo changes from master after reset;

Git update created branch with main changes Switch to created branch. then by using TortoiseGit -> Merge from (pick main branch)

CREATE PULL REQUEST:

1. Be on master branch;

2. Create new branch (feature or task); e.g. aivsim/createSmsPage

3. Switch to created branch;

4. Commit changes to created branch;

5. Push branch to GIT (other users will be able to see it);

6. Got to bitbucket git repository -> Pull requests -> Create pull request; Compare between (master / aivsim/createSmsPage);

7. For reviewers: Go to Bitbucket -> Pull requests -> Review code -> Approve;

8. Pull request creator reviews comments, updates code and does a Merge;