Git version control help

[Joveice]

Hello,

 

I'm trying to understand the git version control, but I'm unable to find good information about it / how you use it.

 

Currently I push to my test repo and test it, if it works I merge it into prod and pull it on to the server. If something goes wrong I don't think I have a good way to rollback.

 

Some information on this would be awesome, links / blog posts with examples highly appreciated.

[jincio]

You should use tag on working version, so that you can easily rollback to the previous tag if something goes wrong.

Here's a link that explain the main guideline :

https://www.atlassian.com/git/tutorials/comparing-workflows

in addition use could use gitflow that use easier command for release tag and feature

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
 

[Mira Yurizaki]

7 hours ago, Joveice said:

Hello,

 

I'm trying to understand the git version control, but I'm unable to find good information about it / how you use it.

 

Currently I push to my test repo and test it, if it works I merge it into prod and pull it on to the server. If something goes wrong I don't think I have a good way to rollback.

 

Some information on this would be awesome, links / blog posts with examples highly appreciated.

Version control in general works like this:

• You have a mainline branch of code called the trunk. This is the code that will be used in released software.
• When you want to make changes in software, you branch off the trunk. You then do development in this branch of code. The reason you do this is if someone else wants to make changes, they can branch off the trunk. This is to ensure that none of their changes are affecting you and vice versa. If you both were to work from the trunk directly, you could potentially pollute each other's work with bugs and other strange behavior. It also pollutes the trunk with software that isn't ready for release (remember, the trunk is supposed to represent tested, stable-as-possible software)
• When you're done with making changes to your branch and you've sufficiently tested it, you merge it back to the trunk. Similarly, if someone else made a branch and is done with it, they also merge it back into the trunk.
• Once all the branches are merged in, you should do a test on the trunk that does the same tests that were done on the branches to ensure they all play nicely with each other.
  • Any changes regarding what the branch is supposed to do should be re-branched from the trunk. This is more of a convenience factor because version control software can flag some changes as conflicts and if you're trying to merge in a branch from an old trunk into a future trunk, it's going to complain loudly. It also makes it harder for you to successfully merge in code, especially if the source file that was touched was touched by a few other branches.
• Once all branches are merged and the trunk tested, you create a tag of the trunk. This is more of a checkpoint so you don't have to find which revision number this finalization occurred.

As an example, I have Super Amazing Software version 1.00 I'm working on.

1. I have the trunk for version 1.00, and I want to do work for a version 1.01 release by adding a few features
2. I first create 1.01's trunk based on 1.00's trunk.
3. I make a branch for each feature I want to add. Each branch will only have that feature implemented.
4. After I test each branch to ensure the new feature works, I merge the branch back into 1.01's trunk.
5. After all the branches are merged in, I do some testing to make sure the software works when everything's together.
6. I find out something is broke and isolate to a particular branch.
7. I rebranch the trunk to make the fix. Then it gets merged in and it all gets retested.
8. Everything passes, so I make a tag for this version. If no other features are planned for this version, it gets released.
   • If there are more features planned, the process restarts from the third step.

Edited March 14, 2018 by M.Yurizaki
Edited a part about testing the trunk after merging in all the branches. It was worded ambiguously.

[Joveice]

Wow! Thanks @M.Yurizaki for the good explanation!

[Joveice]

3 hours ago, M.Yurizaki said:

Version control in general works like this:

• You have a mainline branch of code called the trunk. This is the code that will be used in released software.
• When you want to make changes in software, you branch off the trunk. You then do development in this branch of code. The reason you do this is if someone else wants to make changes, they can branch off the trunk. This is to ensure that none of their changes are affecting you and vice versa. If you both were to work from the trunk directly, you could potentially pollute each other's work with bugs and other strange behavior. It also pollutes the trunk with software that isn't ready for release (remember, the trunk is supposed to represent tested, stable-as-possible software)
• When you're done with making changes to your branch and you've sufficiently tested it, you merge it back to the trunk. Similarly, if someone else made a branch and is done with it, they also merge it back into the trunk.
• Once all the branches are merged in, you should do another test that re-tests all of the branches to ensure they all play nicely with each other.
  • Any changes regarding what the branch is supposed to do should be re-branched from the trunk. This is more of a convenience factor because version control software can flag some changes as conflicts if and if you're trying to merge in a branch from an old trunk into a future trunk, it's going to complain loudly. It also makes it harder for you to successfully merge in code, especially if the source file that was touched was touched by a few other branches.
• Once all branches are merged and the trunk tested, you create a tag of the trunk. This is more of a checkpoint so you don't have to find which revision number this finalization occurred.

As an example, I have Super Amazing Software version 1.00 I'm working on.

1. I have the trunk for version 1.00, and I want to do work for a version 1.01 release by adding a few features
2. I first create 1.01's trunk based on 1.00's trunk.
3. I make a branch for each feature I want to add. Each branch will only have that feature implemented.
4. After I test each branch to ensure the new feature works, I merge the branch back into 1.01's trunk.
5. After all the branches are merged in, I do some testing to make sure the software works when everything's together.
6. I find out something is broke and isolate to a particular branch.
7. I rebranch the trunk to make the fix. Then it gets merged in and it all gets retested.
8. Everything passes, so I make a tag for this version. If no other features are planned for this version, it gets released.
   • If there are more features planned, the process restarts from the third step.

I have a question, I have only figured out that you can add tags to a commit, how would this work out? What I was hoping was that I could mark a merge with a tag or something like that.

[Mira Yurizaki]

3 minutes ago, Joveice said:

I have a question, I have only figured out that you can add tags to a commit, how would this work out? What I was hoping was that I could mark a merge with a tag or something like that.

I'm not familiar with Git's system all that much (I'm more experienced with SVN), so I'll defer you to this: https://stackoverflow.com/questions/18216991/create-a-tag-in-github-repository

[Joveice]

1 minute ago, M.Yurizaki said:

I'm not familiar with Git's system all that much (I'm more experienced with SVN), so I'll defer you to this: https://stackoverflow.com/questions/18216991/create-a-tag-in-github-repository

I'm using Bitbucket, but I'll see if it's the same / if I can find something like that

[Mira Yurizaki]

Just now, Joveice said:

I'm using Bitbucket, but I'll see if it's the same / if I can find something like that

Do they have a Git client? I use TortoiseGit.

[Joveice]

Just now, M.Yurizaki said:

Do they have a Git client? I use TortoiseGit.

Yes, SourceTree

[Cruorzy]

Tagging commits can be done in the command line itself after you commited something.

Git can be used in every way possible you just have to see what work for you.

 

I personally like the Git Flow way of doing it, but for the sake of keeping you code you can also commit everything to master. It ain't a good idea but it is possible.

Don't learn Github or Bitbucket, learn Git.

 

Watch videos about git and the commands it comes with, Git flow commands can be used directly without downloading something I remember.

 

After you've watched some videos about git and it features, i suggest to take a look at Git flow. You don't have to use it but it's a nice way of keeping a structure that is fairly easly learned by other people when they join ur projects.

 

Git flow ain't a program to be clear, it is just a set of rules you should keep to have a structure in your repository. (just like MVC).

[Joveice]

So I just tried the git flow thing, after finishing the release and trying a hotfix the tags where gone, whats the point of the tags then?

 

EDIT:

 

Oooh I had to push the tags too. don't know why I would not want to